[jdev] Bug in jabberd2 (2.1.13) on win32

[Dan Hulme]

Ok, after looking closer, it does not appear to reuse sockets at all,
but reuses the mio structure.  The structure is pretty simple and was
not remembering the old file descriptor, so I just looked at how it
differed (after being used once) from a completely new one.  What I
noticed was that the "revent" and "event" fields were not being reset
on freeing it for reuse.  I zeroed them (it seems only the event must
be cleared):

mio_wsasync.h:68
    static void _mio_free_fd(mio_t m, mio_priv_fd_t priv_fd)            \
    {                                                                   \
        priv_fd->next_free = MIO(m)->next_free;                         \
        priv_fd->mio_fd.fd = 0;                                         \
        priv_fd->revent = 0;                                         \
        priv_fd->event = 0;                                         \
        MIO(m)->next_free = priv_fd;                                    \
    }                                                                   \

And the bug goes away.  Since the socket is available for reuse, it
doesn't make sense to remember the old event flags. This may mean that
an event may arrive that doesn't get handled, of course, but if it
*is* to be handled, the mio struct should not be marked as available
until the event is handled.

In this vein, I have provided a patch which does nothing when
_mio_free_fd is called, but frees it when the FD_CLOSE is received.
It's attached.  It basically replaces mio_free_fd with a dummy
function and moves the functionality to another function.

-Dan



On Jan 24, 2008 11:25 AM, Dan Hulme <dhulme at gmail.com> wrote:
> I had forgotten, but this is the case.  Here is confirmation:
>
> http://msdn2.microsoft.com/en-us/library/ms740481(VS.85).aspx
> > An application should not rely on being able to reuse a socket after it has been shut down.
> > In particular, a Windows Sockets provider is not required to support the use of
> > 'connect' on a socket that has been shut down.
>
> So the win32 implementation should not be pooling sockets, I guess.
>
> -Dan
>
>
> On Jan 24, 2008 12:51 AM, Norman Rasmussen <norman at rasmussen.co.za> wrote:
> > On Jan 24, 2008 2:14 AM, Dan Hulme <dhulme at gmail.com> wrote:
> >
> > > This function appears to try to append the old closed socket to a
> > > linked list of free sockets.  When the new connection tries to use
> > > this socket, it has trouble.  Once the next connection connects,
> > > however, it will not use that socket as it is still in use, so it will
> > > work.  Not sure why the socket that is being appended is broken, but
> > > if this function is not called (at mio_impl.h: 267), the program works
> > > "fine."  It may not be reusing sockets, but everything else works.
> > >
> >
> > In my experience win32 does weird things with closed sockets: if you close a
> > listening socket, it doesn't actually go away until all connected clients do
> > too.  It sounds like this is similar, and that perhaps for win32 you
> > shouldn't be trying to pool sockets.
> >
> > --
> > - Norman Rasmussen
> >  - Email: norman at rasmussen.co.za
> >  - Home page: http://norman.rasmussen.co.za/
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mio_wsasync.h.diff
Type: application/octet-stream
Size: 2567 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20080124/8cb7cf4e/attachment-0002.obj>