Jeff Trawick wrote:
> . apr_send() hands the data straight to the TCP/IP stack; it does not
> buffer data, so there is no need for apr_socket_flush()
Ok.
> . if your APR socket has a timeout set or is non-blocking, apr_send()
> can write fewer bytes than you requested... check the output
> bytes-written status
>
> If no bytes are going to the wire, what is happening in the TCP layer?
> Can you use netstat to display info about the TCP connection? Maybe
> there are already bytes in the send buffer and the TCP stack can't
> accept any more because the other side isn't acknowledging bytes
> already sent?
A check with netstat shows:
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address
State
tcp 0 41 cbs53-01-p87.wc.sa:1777 atlas.thawte.com:https
CLOSE
which is rather odd - the connection is set up using
apr_socket_create(), then opened with apr_connect(), then sent to with
apr_send(). Is this the correct sequence of events? Why the CLOSE?
Regards,
Graham
--
-----------------------------------------
[EMAIL PROTECTED] "There's a moon
over Bourbon Street
tonight..."
