wxFtp.Connect() blocks due to socket problem

[Thomas Zehbe]

Am Mittwoch, 1. November 2006 02:51 schrieb Vadim Zeitlin:
> On Tue, 31 Oct 2006 19:46:30 +0100 Thomas Zehbe <tz at ingenion.de> wrote:
>
> TZ> It's not really easy to understand the socket stuff :-)
>
>  No... this comes from the absence of a dedicated maintainer for it,
> unfortunately.
>
> TZ> I'm not sure wether wxProtocol::Readline should Peek with the "right"
> size TZ> until there's nothing more or Peek should be modified that it's
> not reading TZ> more if there still is unread buffer.
>
>  I don't see how can it know the "right" size. I'm pretty sure Peek()
> should return without blocking in any case...
I found a solution last evening and tested it now. I modified Peek() to 
prevent it from unconditionally make a _Read() on the socket with the givern 
peeking buffer size. I do what _Read() does at first. Try to GetPushback() 
the buffer. If GetPushback() messages that there are unread bytes, I set 
m_lcount to this value (just as is happens with the _Read() result) and 
return.

The implication is that any app that once has peeked the socket stream is 
resonsible for emptying the peeked buffes content by doing enough Read()s on 
it. Only Peek()s with an empty pushback buffer would start a read ond the 
socket.

Readline() from wxProtocol behaves just like this. It looks for a cr-lf pair 
in the given buffer and if there is none, it Read()s the rest an then Peek()s 
again.

I reduced Readlines buffersize to 25 bytes and all works as expected (maybe 
not as efficient :-). I tested this with the socket sample and this works, 
too.

So if you don't see any other sideeffects, I'll upload a patch to the sf 
tracker. Peek() would still block, if during the first Read() after getting a 
valid blocking socket fd the the server doesn't send any greeting sequence.

Regards,

Thomas


>
>  Regards,
> VZ

-- 
Dipl.-Ing. Thomas Zehbe
INGENION GmbH
Kuhweide 6
31552 Apelern
Fon: 05043 / 40 57 90 4
Fax: 05043 / 40 57 90 7