RE: [Libevent-users] Proper socket shutdown.

["Kelly Brock" <Kerby@xxxxxxxxxxx>]

Hi,

	Writing this in between errands.

> >        Just a note before the details.  I would suggest adding a little
> > section to the manual covering the proper method of handshaked shutdown.
> > It's just a minor thing but figuring out the watermark method is non-
> obvious
> > till you give it some further thought.  (Well, it was to me at the time,
> > then again it was 2am. :))
> 
> Sure!  Want to take a crack at writing it?  The source is at
> http://github.com/nmathewson/libevent-book .  It would probably be
> neat to add a series of "Cookbook" chapters.

	Will consider it once we figure out the problem, seems a bit more
important to get iocp fully functional right now.

> Instead of doing the watermark trick, I usually have a callback that
> checks whether evbuffer_get_length(bufferevent_get_output(bev)) is 0,
> does a socket shutdown if it is, but the watermark way is probably...
> better?

	The reason I went this way was that I can have 0 bytes outstanding
at anytime and it is only valid to shutdown when the connection wrapper
object is in a proper state for it.  So, the real code actually sets a flag
and also changes the callback before changing the watermarks.

> >        Anywhere, here is a quick and dirty testbed for the problem.
> >
> > http://pastebin.com/QF4N2DEw
> >
> >        If you leave "USE_IOCP" set to 0 everything shuts down correctly.
> > If you turn that flag on though, the EOF's are never seen.  I just got
> this
> > test case functional so forgive the dirty leaky implementation if you
> will,
> > but please do check that I'm not just making some other stupid error as
> I'm
> > still getting used to 2.0 changes.
> 
> Reading the code, just a few (minor) comments that shouldn't affect
> anything really:

	Yup, good feedback, I have all those done correctly in the real
code, I got lazy/sloppy trying to get this up and functional as fast as
possible.

> In particular, we should make sure that closing a socket without doing
> a proper shutdown does at least trigger *some* event.
>
> As for the main bug here... I'm seeing hints on MSDN that shutdown()
> may not work properly in tandem with IOCP sockets, and that
> WSASendDisconnect or DisconectEx might be a better choice for those.

	Hmm, I've never had to use those for my work, shutdown always worked
correctly and worked fine with IOCP.  On the other hand, who knows sometimes
what MS is doing anymore, IOCP is a huge hornet nest of goof ball behaviors.

	In the same vein of information though, here are a couple items I
noted while starting to debug a bit:

1.	It is suggested to use "WSASocket" with the overlapped flag instead
of "socket".  This has been a problem in the past but I thought they had
corrected it.  (Changed all socket creation locally, it did not help by
itself.)

2.	When AcceptEx completion returns you are supposed to call:

err = setsockopt( sAcceptSocket, 
    SOL_SOCKET, 
    SO_UPDATE_ACCEPT_CONTEXT, 
    (char *)&sListenSocket, 
    sizeof(sListenSocket) );

	This is in order to inherit some settings and get the socket in a
proper state.  Never had to do this but who knows if this is the problem in
conjunction with WSASocket not being used.

3.	IOCP can be interrupted quite often by external applications.  I did
not see this happening but checked anyways.  Basically you can get a
WSAEINTR which is "NOT" an error or a cancellation.  It's a seriously stupid
design flaw since this same error is used if you cancel an operation (don't
think you use cancel anywhere), if QOS services decide to interrupt your
send/recv (happens pretty damned randomly once you have any notable amount
of network trafic), or if another program does something lowish level which
causes a lock at the nic interface level.

	I wasn't sure what the code would do in the interrupt case but it
really should just re-issue send/recv's unless you or the user starts using
the cancel functionality.  I HIGHLY suggest avoiding cancellations since it
is seriously broken prior to Vista.


	Those were the things I noticed while starting to poke around.  I'll
be back to lookin in a while, though with the intended beer, maybe not a
good thing to poke about at the code. :)

KB

***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.