SocketStream>>flush question

C. David Shaffer cdshaffer at acm.org
Mon Mar 8 06:09:20 UTC 2004


Lex Spoon wrote:

>"C. David Shaffer" <cdshaffer at acm.org> wrote:
>  
>
>>    1) Why would isOtherEndConnected be true but isConnected be false?  
>>VM/socket plugin bug?  There are no documented semantics of isConnected 
>>so I have no idea what it means.  isOtherEndConnected seems, for some 
>>reason, exclusive of "isConnected not" (the status is checked with ==, 
>>not a mask).  What are the semantics of this method?  I would think 
>>Socket>>isOtherEndClosed would look more like ^self isClosed or: [insert 
>>current code here].
>>    
>>
>
>isConnected means "is fully connected".  If you are only interested in
>whether one side is still sending, then you need to ask a more specific
>question.
>  
>

Thanks for clarifying and I assume by "you" that you really mean "the 
author of SocketStream>>flush" since I had nothing to do with the code 
cited.  What I really needed to know was: should I post a fix for this 
or am I missing something but you seemed to have answered that below.  
Anyway, we seem to agree on the overall situation (towards the end of 
the post).

>
>  
>
>>    3) even if you fix this problem, the "self error: 'whatever'" style 
>>handling of primitive failures is not very useful.  There is a race 
>>condition between the check of socket "closed" status and the sending of 
>>data so the primitive could fail even if my test for an open socket 
>>succeeded.  
>>    
>>
>
>Oh yes.  This is inherent in networking.  The BSD sockets API handles
>this in just the way you expect, given the problem:
>  
>
Yes, the sockets API gives me a clear cut way to determine if a 
connection was closed on the other end.  Squeak's interface to it, 
unfortunately does not.  How can I tell if the "primitive failed" b/c 
the other end was closed or if it had some kind of internal failure?  If 
I get a primitive failure in a call to SocketStream>>next can I assume 
that socketError will return a usefull error code?  What if the 
primitive failed but not because of a socket error?  As you say below, 
and as I think I was pointing out quite clearly here, the error 
mechanism currently in place is not useful.


>>The error: mechanism leaves me little to do defensively but 
>>trap Error and check the text of the message or the context.
>>    
>>
>
>
>Well, BSD sockets uses -1 instead of Error, but it's the same idea.  You
>have to just try your read() or write() and then check whether it
>worked.
>  
>

I'm not so sure about that.  A read on a socket closed on the other end 
should return "zero bytes" to the best of my recollection.  Also, I 
don't agree that its the same idea.  The sockets version "returns" a 
useful error code, squeak burries it in a generic exception and the 
"Socket>>socketError" mechanism (which appears to be unused and unusable 
due to the question of what "the last socket error" really means since I 
can't tell if there was really a socket error or if the primitive failed 
because it couldn't find my Aunt Mary's phone number).  As I think I 
stated quite clearly, the problem isn't the socket error handling 
mechanism, it's squeak's abstraction on it.  There's probably some 
patchwork one can do to fix this up...again, I just needed to know if I 
was missing something.


>
>  
>
>>This is a horrific abomination :-)  
>>    
>>
>
>Well, you know, the universe does not always have the most convenient
>semantics.  :)  
>  
>
It isn't the semanitcs of BSD sockets to lose information about why an 
error occurred, it just seems to be the existing squeak code which 
obscures this info.

>
>IMHO, the best immediate "fix" is to be sure that proper exceptions are
>used so that you don't have to catch the generic Error.
>


Bingo.  That's what I'll have to do...assuming it is even possible based 
on the existing plugin code.  I haven't looked at it, in fact I'm afraid to.

>  Other than
>that, things look pretty good.  It may be possible to do better, but it
>will take a whole new approach to sockets, not a tweak here and there. 
>Networks are asynchronous, and you simply cannot rely on them to sit
>still while you talk to them.
>  
>
Isn't this part of what Flow does?  Really, all _I_ want is a decent 
mapping of the sockets API into Squeak and into the Stream framework.  I 
don't mind catching exceptions I just want to catch more specific ones.  
If you read any more into my post (ie that I was seeking something 
beyond the sockets API) then you're reading my mind and not what I typed :-)

>Also, this area horribly needs some documentation.
>
>	1. The proper error handling approach should be described somewhere.
>	
>	2. The semantics of close should be documented.  At least on Unix, it
>means "I promise not to send any more data".  It is perfectly allowed to
>#close and then #receiveData: however.
>  
>

Yes and yes!  So squeak's close is sockets 1/2 close (shutdown) 
operation?  That's interesting and yes, it should be documented since it 
is quite unexpected.


Thanks so much for your helpful comments Lex, I feel reassured that I 
can proceed to try to patch up SocketStream and Socket for my current 
work.  Maybe if I post some code to BFAV I'll get additional feedback on 
what I'm proposing.


David




More information about the Squeak-dev mailing list