This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients François-Xavier.Bourlet, neologix
Date 2011-07-24.20:51:16
SpamBayes Score 1.4052978e-09
Marked as misclassified No
Message-id <1311540678.07.0.080079698738.issue12498@psf.upfronthosting.co.za>
In-reply-to
Content
Hello,

> Actually the class asyncore.dispatcher_with_send do not handle properly
> disconnection. When the endpoint shutdown his sending part of the socket,
> but keep the socket open in reading, the current implementation of
> dispatcher_with_send will close the socket without sending pending data.

Yes, that's a common problem with "naive" networking code.

> Note also that this class try to initiate a send even if the socket is maybe
> not ready for writing:
>
> Here's a simple fix:
>     def send(self, data):
>         if self.debug:
>             self.log_info('sending %s' % repr(data))
>         self.out_buffer = self.out_buffer + data
> -       self.initiate_send()
>

Hum, I'm not sure about this.
dispatcher is just a thin wrapper around the underlying socket, so the
semantic of `send` should be the same as `socket.send`, i.e. just call
the send(2) syscall. I think it's the application's reponsibility to
check that the socket is indeed writable, and to cope with potential
failures (e.g. EAGAIN or ENOTCONN).

> Last but not last, the buffer size of each socket send are way to small
> (512, a third of an usual TCP frame). Here's the code with a bumped value:

Indeed, 1/3 of the ethernet MTU is quite small.

Would you like to submit a patch?
History
Date User Action Args
2011-07-24 20:51:18neologixsetrecipients: + neologix, François-Xavier.Bourlet
2011-07-24 20:51:18neologixsetmessageid: <1311540678.07.0.080079698738.issue12498@psf.upfronthosting.co.za>
2011-07-24 20:51:17neologixlinkissue12498 messages
2011-07-24 20:51:16neologixcreate