Message141057
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? |
|
Date |
User |
Action |
Args |
2011-07-24 20:51:18 | neologix | set | recipients:
+ neologix, François-Xavier.Bourlet |
2011-07-24 20:51:18 | neologix | set | messageid: <1311540678.07.0.080079698738.issue12498@psf.upfronthosting.co.za> |
2011-07-24 20:51:17 | neologix | link | issue12498 messages |
2011-07-24 20:51:16 | neologix | create | |
|