homepage

I am currently busy, but i will try to allocate some time to propose a
path soon.
Cheers,
2011年7月24日 Charles-François Natali <report@bugs.python.org>:
>
> Charles-François Natali <neologix@free.fr> added the comment:
>
> 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?
>
> ----------
> nosy: +neologix
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue12498>
> _______________________________________
>