[Gambas-user] Support for IMAP in gb.net.curl

[Benoît Minisini]

Le 24/09/2017 à 04:07, Tony Morehen a écrit :
> I came across an interesting issue when working on Imap's Fetch 
> command.  Fetch is used to down load messages.  The response to a Fetch 
> has 4 parts:
> 1) a single line providing the size of the download, say, 69000 bytes.
> 2) the mime-encoded download (a string 69000 bytes long)
> 3) one line whose only contents is ")"
> 4) one line status line.
> 
> So my code does:
> Readline
> response = Read #stream, iSize    'iSize=69000
> Readline
> Readline
> 
> Using a TCP socket,  the Read # line has no error but the download is 
> incomplete, say only 50000 bytes.  The remaining 19000 byes is read by 
> the next Readline.  However, the response variable is the correct 69000 
> bytes in length, with the last 19000 bytes zero-filled.  Its like the 
> Read # timed out but the timeout is set to 10000 and 10 seconds had not 
> elapsed.  Socket.blocking was set to True.
> 
> Using an openssl process, the Read # line raises an error:  Error 9, Bad 
> file descriptor.
> 
> I have a workaround:  Read # is replaced with
> 
>    Dim result as new String[]
> 
>    Bytesread=0
>    Do While BytesRead < iSize
>      Response = Read #$hStream,  IIf(iSize - BytesRead > 4096, 4096, 
> iSize - BytesRead)
>      result.Add(Response)
>      bytesread += 4096
>    Loop
>    Response = result.Join("")
> 
> Now both TCP and openssl work, no zero-fill no errors.
> 
> Any ideas? Other fixes?
> 
> 

I looked at the gb.net socket source code (which I didn't wrote), and 
things are clear: the read method of the Socket class stream just do one 
system call. So it does not read what the user asks, but what is 
available on the socket.

Other streams implemented in the interpreter (like pipe, for example), 
on the contrary, try to read the number of bytes requested by the user.

Your code implements the missing logic in gb.net, so it fixes the 
problem (as 4096 may be the granularity of TCP data that is sent to the 
user space).

I have to fix that directly in gb.net. Of course it's a pity that each 
stream has to implement the same logic, so maybe I should take more time 
to see I can find a solution directly in the interpreter.

-- 
Benoît Minisini