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

[Tony Morehen]

There's not much logic behind the 4096.  It was the first number I tried 
and it worked.  I originally used 4096 in a copy routine in a file 
manager program.  There, 4096 makes sense as it equals a hard drive 
cluster size.


On 2017-09-24 04:06 PM, Benoît Minisini via Gambas-user wrote:
> 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.
>