[Libevent-users] cha-ching!
Kevin Sanders
newroswell at gmail.com
Wed Feb 28 12:32:55 EST 2007
On 2/28/07, Toby Douglass <toby.douglass at summerblue.net> wrote:
>
> > On 2/27/07, Toby Douglass <toby.douglass at summerblue.net> wrote:
>
> >> Not really a bug as such - a documentation bug, if you like.
> >>
> >> If you call AcceptEx() and specify a non-zero read buffer size,
> >> GetQueuedCompletionStatus() will NOT return on a connect. It will only
> >> return when some data is sent.
>
> > *dwReceiveDataLength* [in] Number of bytes in *lpOutputBuffer* that will
> > be
> > used for actual receive data at the beginning of the buffer. This size
> > should not include the size of the local address of the server, nor the
> > remote address of the client; they are appended to the output buffer. If
> *
> > dwReceiveDataLength* is zero, accepting the connection will not result
> in
> > a
> > receive operation. Instead, *AcceptEx* completes as soon as a connection
> > arrives, without waiting for any data.
>
> That's the section I was thinking of when I described the behaviour as
> undocumented.
>
> The behaviour in question is this: if you set the buffer size in
> AcceptEx() to a value larger than 0, GetQueuedCompletionStatus() will not
> return a completed I/O packet on the accept operation until a read
> operation completes.
>
> What the docs say is this: "If dwReceiveDataLength is zero, accepting the
> connection will not result in a receive operation. Instead, *AcceptEx*
> completes as soon as a connection arrives, without waiting for any data."
>
> Which is to say: if you specify a zero length buffer, you won't get a
> receive operation with your accept completion; instead, you'll only get an
> accept.
Right. It's either going to wait for the initial read or not.
This is insufficient, because it says nothing about the behaviour in the
> case of an accept where no data is being sent. Do you get an accept
> completion or not? all you know is that if you set the buffer to 0, you
> would get an accept completion.
It waits (and waits, and waits forever) for the initial data to arrive.
Down the page, in the Remarks section, among several C code examples, it
states;
If a receive buffer is provided, the overlapped operation will not complete
until a connection is accepted and data is read. Use the
*getsockopt*<getsockopt_2.htm>function with the SO_CONNECT_TIME option
to check whether a connection has
been accepted. If it has been accepted, you can determine how long the
connection has been established. The return value is the number of seconds
that the socket has been connected. If the socket is not connected, the *
getsockopt* returns 0xFFFFFFFF. Applications that check whether the
overlapped operation has completed, in combination with the SO_CONNECT_TIME
option, can determine that a connection has been accepted but no data has
been received. Scrutinizing a connection in this manner enables an
application to determine whether connections that have been established for
a while have received no data. It is recommended such connections be
terminated by closing the accepted socket, which forces the
*AcceptEx*function call to complete with an error.
Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://monkeymail.org/archives/libevent-users/attachments/20070228/36e8ca35/attachment-0001.htm
More information about the Libevent-users
mailing list