Obtaining the client's host name
Hi, Is it possible using the API to obtain the client's host name - i.e. a reverse DNS lookup? If not I guess it is safe to use gethostbyaddr_r to look it up from the client's IP address. Thank-you, Chris Reynolds.
Re: Obtaining the client's host name
There is no API to get the client hostname. I recommend doing the gethostbyaddr_r directly as any API would simply be a wrapper around that. Monday, August 8, 2011, 4:26:40 AM, you wrote: Hi, Is it possible using the API to obtain the client's host name - i.e. a reverse DNS lookup? If not I guess it is safe to use gethostbyaddr_r to look it up from the client's IP address. Thank-you, Chris Reynolds.
Re: Obtaining the client's host name
I would think we'd need to provide a convenience function that uses the DNS subsystem to do PTR record lookups. On Mon, Aug 8, 2011 at 10:06 AM, Alan M. Carroll a...@network-geographics.com wrote: There is no API to get the client hostname. I recommend doing the gethostbyaddr_r directly as any API would simply be a wrapper around that. Monday, August 8, 2011, 4:26:40 AM, you wrote: Hi, Is it possible using the API to obtain the client's host name - i.e. a reverse DNS lookup? If not I guess it is safe to use gethostbyaddr_r to look it up from the client's IP address. Thank-you, Chris Reynolds. -- Theo Schlossnagle http://omniti.com/is/theo-schlossnagle
Re: Obtaining the client's host name
On 08/08/2011 08:09 AM, Theo Schlossnagle wrote: I would think we'd need to provide a convenience function that uses the DNS subsystem to do PTR record lookups. Agreed. I think we should provide the equivalent of TSHostLookup(), but for PTR lookups. -- Leif
bnull-transform.c: SIGPIPE on connection termination
Hello, I'm using the bnull-transform example and sometimes if connections are terminated abruptly it can cause a SIGPIPE, I've spent a good amount of time trying to track down the cause and have been unable to do so. Also, the bnull-transform.c code isn't up to date with the latest API so I attached a patch that will correct the datatypes in handle_buffering() from int to int64_t, also, I added a few casts to prevent errors when compiling with -Wall. To reproduce the bug I'm using ab with a high level of concurrency and killing ab to force the connections closed, the following command will demonstrate this: for (( ; ; )) do ab -n 1 -c 210 http://127.0.0.1:8000/skeleton sleep 2; killall ab; done; After a few iterations of killing ab it should cause a SIGPIPE in traffic_server. As I've said, I've looked into this for quite a while before emailing this list so any help or advice would be greatly appreciated. Best, Brian
