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.
------------------------------------------------------------------------------
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
