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
|