Good to know, that you're working on it. Took me a while to figure out that 
#next: would not fill the entiry buffer...

Unfortunately, I wasn't able to resolve my afore mentioned problem completely. 
To make things easier, I sent #upToEnd to my SocketStream, expecting to get all 
the data (and then read the lines later). However, towards the end of the 
transmission the connection is suddenly closed (ConnectionClosed is signaled by 
Socket>>waitForDataFor:) and I lose a variable amount of data (up to about 
300KB out of 4.7MB). The primitive says that the server closed the connection 
(which might of course be true) but I can't see where my data went missing.

In one case I even had a singel byte missing inside a line (the line was one 
byte shorter than advertised). Now this would probably be a totally different 
proplem and, to be fair, I couldn' reproduce it, so ignore this for now.

Camillo is now looking into ithe SocketStream stuff but if any of you have a 
clue what could be going on, I'd appreciate your help.

Cheers,
Max

On 15.01.2012, at 20:56, Stéphane Ducasse wrote:

> 
> On Jan 15, 2012, at 8:10 PM, Schwab,Wilhelm K wrote:
> 
>> Max,
>> 
>> I wouldn't forget it too soon.  Streams should work as advertised or raise 
>> an error.  My (compromise) proposal remains as follows:
>> 
>>   http://code.google.com/p/pharo/wiki/StreamsForRobustSoftware
> 
> Yes :)
> 
> I know.
> 
>> 
>> Bill
>> 
>> 
>> ________________________________________
>> From: pharo-project-boun...@lists.gforge.inria.fr 
>> [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Max Leske 
>> [maxle...@gmail.com]
>> Sent: Sunday, January 15, 2012 6:18 AM
>> To: pharo-project@lists.gforge.inria.fr
>> Subject: Re: [Pharo-project] reading *exactly* n bytes from socket
>> 
>> Sorry, forget what I just wrote…
>> I found the bug in my code. Should have checked if the connection is still 
>> open :-/
>> 
>> Cheers,
>> Max
>> 
>> 
>> On 15.01.2012, at 12:09, Max Leske wrote:
>> 
>>> Hey guys
>>> 
>>> I'm having a problem with Socket / SocketStream. When I know that the next 
>>> packet of data from the server is going to be 10'000 bytes I want to ask 
>>> the socket for exactly 10'000 bytes of data (I don't care how long it 
>>> takes). However, the comments in the Socket class suggest that the buffer 
>>> might not be filled entirely when the message answers. As a consequence, my 
>>> code fails because the ByteArray sometimes has a number of zero bytes at 
>>> the end which obviously wasn't expected.
>>> I also tried to use SocketStream to get around this problem but wasn't 
>>> successful. Am I supposed to handle this case myself or did I overlook 
>>> something?
>>> 
>>> Cheers,
>>> Max
>> 
>> 
>> 
> 
> 


Reply via email to