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
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gambas-user mailing list
Gambas-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gambas-user
