schizo-socket

I'm looking at a socket in my debugger.

The socket responds false to:  >>readWaitWithTimeoutMs: 100

... thus indicating that the socket *has* data available to read

The socket reponds 0 (zero) to: >>bytesForRead

... thus indicating that the socket has zero bytes available to read

???

How is this possible?

Thanks,
    Bruce
--
Make the most of your skills - with OpenSkills
http://www.openskills.org/

Bruce Badger wrote:

Usually when the other end has closed the connection. That's actually
the only indication that you get.

On 28/02/06, Martin Kobetic <[hidden email]> wrote:
> > The socket responds false to:  >>readWaitWithTimeoutMs: 100
> > ... thus indicating that the socket *has* data available to read
> > The socket reponds 0 (zero) to: >>bytesForRead
> > ... thus indicating that the socket has zero bytes available to read
> > How is this possible?
>
> Usually when the other end has closed the connection. That's actually
> the only indication that you get.

Would it be too much to ask that >>bytesForRead call
>>readWaitWithTimeoutMs: and throw an exception in this situation?

This surprised me and I use sockets quite a bit.  Making the situation
clearer would be Really Good, I think.

Worth an AR?  I think so.

--
Make the most of your skills - with OpenSkills
http://www.openskills.org/

Bruce Badger wrote:
>>Usually when the other end has closed the connection. That's actually
>>the only indication that you get.
>
> Would it be too much to ask that >>bytesForRead call
>>>readWaitWithTimeoutMs: and throw an exception in this situation?

I'm not sure about that. Wouldn't it potentially block bytesForRead ?

> This surprised me and I use sockets quite a bit.  Making the situation
> clearer would be Really Good, I think.

> Worth an AR?  I think so.

I would have to open Stevens again to be sure but I have a vague
recollection that detecting orderly closure may not be as
straightforward as one would hope. So it's not clear to me exactly how
much better we can do. Until then I'm not ready to create an AR.

On 01/03/06, Martin Kobetic <[hidden email]> wrote:
> Bruce Badger wrote:
> >>Usually when the other end has closed the connection. That's actually
> >>the only indication that you get.
> > Would it be too much to ask that >>bytesForRead call
> >>>readWaitWithTimeoutMs: and throw an exception in this situation?
>
> I'm not sure about that. Wouldn't it potentially block bytesForRead ?

It seems that readWaitWithTimeoutMS: returns immediately if there is data.

> I would have to open Stevens again to be sure but I have a vague
> recollection that detecting orderly closure may not be as
> straightforward as one would hope. So it's not clear to me exactly how
> much better we can do. Until then I'm not ready to create an AR.

As in "Unix Network Programming"?  I have a copy here :-)

But really all I'm suggesting is that a VW programmer experiences some
sanity.  Having a socket first say there *is* some data and then when
asked for it denying that there is any is not sane at all.

Whether this indicates a lost connection, as you suggested, is a
secondary thing from my POV.

All the best,
    Bruce
--
Make the most of your skills - with OpenSkills
http://www.openskills.org/

Bruce Badger wrote:
>
> But really all I'm suggesting is that a VW programmer experiences some
> sanity.  Having a socket first say there *is* some data and then when
> asked for it denying that there is any is not sane at all.

It is not saying there is data: it quite literally says that it is done
waiting.

It is more like #atEnd, which will return if data is available or the stream
is closed, but will block otherwise.



HTH,

Reinout
-------

On 01/03/06, Reinout Heeck <[hidden email]> wrote:
> Bruce Badger wrote:
> >
> > But really all I'm suggesting is that a VW programmer experiences some
> > sanity.  Having a socket first say there *is* some data and then when
> > asked for it denying that there is any is not sane at all.
>
> It is not saying there is data: it quite literally says that it is done
> waiting.

Then what is the meaning of the boolean returned by readWaitWithTimeoutMS: ?

I understood that result of true simply meant that the timeout had
been reached, i.e. it had done waiting, as you suggest.

According to the comment in the method, returning false indicates that
there is data to be read.

So, what I saw was:

readWaitWithTimeoutMS: returns false.  i.e. there *is* data to be read

bytesForRead returns zero.  i.e. there are *no* bytes to be read

What am I missing here?

Thanks, and sorry I'm being a bit slow.
    Bruce
--
Make the most of your skills - with OpenSkills
http://www.openskills.org/

Bruce Badger wrote:
Right, the comment is misleading:

        "Wait until the accessor has data available for reading, or
        the timeout expires."
        "Answer true if timeout expired."

Strictly it should say something like "wait until the accessor will not block
on a subsequent read operation" but I fear a lot of people would not easily
understand that unless they already know 0-byte reads are possible.


Somewhat more loosely:
        "Wait until the accessor has data available for reading,
        or the connection is closed, or the timeout expires."
        "Answer true if timeout expired."
but this might fail to enumerate some other situations in which it will return
false.



HTH,

Reinout
-------

On 01/03/06, Reinout Heeck <[hidden email]> wrote:
> Bruce Badger wrote:
> > Then what is the meaning of the boolean returned by readWaitWithTimeoutMS:

> Strictly it should say something like "wait until the accessor will not block
> on a subsequent read operation" but I fear a lot of people would not easily
> understand that unless they already know 0-byte reads are possible.
> Somewhat more loosely:
>         "Wait until the accessor has data available for reading,
>         or the connection is closed, or the timeout expires."
>         "Answer true if timeout expired."
> but this might fail to enumerate some other situations in which it will return
> false.

OK - but is this sane?

What is the point of readWaitWithTimeoutMS: returning an indication
that it's OK to read when there is nothing to be read?

I undersatand that the socket will allow us to read zero bytes in this
situation, but surely this is futile.  It smacks of someone playing a
too-clever game.

What problems would be caused if readWaitWithTimeoutMS: returned an
indication that there was data to be read *only if there really were
bytes to be read*?

If the socket has a problem, why can't we have an exception being thrown?

What's happened to "Intention Revealing" here?

> HTH,

It does help.  Thank you.  Forgive me for wanting more, though :-]

All the best,
   Bruce
--
Make the most of your skills - with OpenSkills
http://www.openskills.org/

Bruce Badger wrote:
I think you're forcing particular interpretation on it. It returns when
connection closes because there's no point waiting any more. It is not a
timeout, so it returns false. As Reinout said it doesn't mean there is
more data to read, but it does mean that when you attempt to read, you
won't block. That is the primary purpose of it, being able to control
blocking.

> I undersatand that the socket will allow us to read zero bytes in this
> situation, but surely this is futile.  It smacks of someone playing a
> too-clever game.
>
> What problems would be caused if readWaitWithTimeoutMS: returned an
> indication that there was data to be read *only if there really were
> bytes to be read*?
>
> If the socket has a problem, why can't we have an exception being thrown?

I'm not convinced that orderly closed connection warrants an exception.
It doesn't seem like a naturally exceptional event, since any connection
is destined to close eventually. But I admit that it is a rather
subjective stance as well. More pragmatically though I don't see this
changing. There's a lot of code out there that doesn't expect that.

Now I'm not saying that this API is perfect. An exception from readWait
doesn't sound like an improvement to me, though. I think the best
approach at this point would be crafting something more "sensible" on
top of this.

Moreover, I still suspect that the existing API is largely motivated by
the standard socket API, and not being wildly different from a well
known, widely adopted API has its value as well.

If that's true it would be good to have both, the familiar and the best :-).

Martin

On 02/03/06, Martin Kobetic <[hidden email]> wrote:
> Bruce Badger wrote:
> > OK - but is this sane?
> > What is the point of readWaitWithTimeoutMS: returning an indication
> > that it's OK to read when there is nothing to be read?

> I think you're forcing particular interpretation on it.

Ah, excuse me for one moment: Aaaaarrrrrggggghhhh!!!!

Right.

The interfaces provided to a VW programmer do not map 1-1 to the BSD
socket library (or the Linux implementation thereof) in C.  There is
already some "interpretation" there.  If there is to be
interpretation, I'm asking that it be "Intention Revealing" aka sane.

So:

If there is a problem with a socket such that I can't use it any more
I'd like an exception, please.  Sockets are not created in order to
fail, thus a failure is exceptional from the programmers point of
view.

If I ask a working socket to let me know if there is some data ready
to be read, I expect the answer to be honest.  If it says there *is*
data there I should be able to get more than zero bytes when I ask the
socket to hand it over!

I'm all for having socket classes that add no "interpretation" and
gives access to everything a socket can do ... but given that that the
VW socket stuff is already an "interpretation" it may as well be a
sane one.  What we have now is neither one thing nor the other, and is
thus a bugger to work with.

All the best,
   Bruce
--
Make the most of your skills - with OpenSkills
http://www.openskills.org/

Bruce Badger wrote:
The mechanism provided shows the abstraction at the VM/Image interface, no
interpretation there really, it merely exposes how the VM uses Semaphores for
synchronization between the Berkely API and the VM's green threads.

If you want an interpretation <grin> where certain socket states throw an
exception when in #readWait the library provides all the mechanism for you to
implement such a method...

The current interface requires some knowledge before you can use it, throwing
an Exception would allow for more exploratory style programming. However if
you do know the Berkely API the provided mechanism is not surprising at all.

>
> If I ask a working socket to let me know if there is some data ready
> to be read, I expect the answer to be honest.

Right, but as explained before you are not asking that.
If you want to ask a socket whether data is available, you or someone else
will have to provide an implementation that answers that question. The
current method only answers whether the timeout expired. Availability of data
is answered by other methods.

> If it says there *is*
> data there I should be able to get more than zero bytes when I ask the
> socket to hand it over!

May I ask, why aren't you sticking with the TCP Stream level of abstraction?
Why are you digging into the guts of the streams "interpretation" of network
sockets? You seem to be bringing this onto yourself, is this by necessity?


>
> I'm all for having socket classes that add no "interpretation" and
> gives access to everything a socket can do ... but given that that the
> VW socket stuff is already an "interpretation" it may as well be a
> sane one.  What we have now is neither one thing nor the other, and is
> thus a bugger to work with.

As said above I do not think the current interface is an "interpretation" of
the interface between VM and image.



Success!

Reinout
-------

On 02/03/06, Reinout Heeck <[hidden email]> wrote:
> Bruce Badger wrote:
> > The interfaces provided to a VW programmer do not map 1-1 to the BSD
> > socket library (or the Linux implementation thereof) in C.

> The mechanism provided shows the abstraction at the VM/Image interface, no
> interpretation there really, it merely exposes how the VM uses Semaphores for
> synchronization between the Berkely API and the VM's green threads.

OK, I can see that.  The classes in VW reflect how the VW VM works,
not how the BSD socket library may appear to, say, a C programmer.

> If you want an interpretation <grin> where certain socket states throw an
> exception when in #readWait the library provides all the mechanism for you to
> implement such a method...

I have.  It's in Sport now.  I do think it's worth trying to make VW
sane for everyone, though.

> The current interface requires some knowledge before you can use it, throwing
> an Exception would allow for more exploratory style programming. However if
> you do know the Berkely API the provided mechanism is not surprising at all.

Only loosely.  As you noted above - the VW classes map to how the VW
VM does things, not how a c programmer might interact with BSD
sockets.

> ... The
> current method only answers whether the timeout expired. Availability of data
> is answered by other methods.

This is simply not the case.  Look at the code.

IOAccessor>>readWaitWithTimeoutMs: returns a Boolean indicating one of
two possibilities.  The first (returning True)  is the the timeout
expired without any data becoming available.  The second (returning
False) is that data became available while waiting.

The comment says: "Wait until the accessor has data available for reading, or
the timeout expires. ... Answer true if timeout expired.".  Note the
"... has data available for reading ..." bit.

> May I ask, why aren't you sticking with the TCP Stream level of abstraction?
> Why are you digging into the guts of the streams "interpretation" of network
> sockets? You seem to be bringing this onto yourself, is this by necessity?

I'm sticking to what seemed like the way one should use TCP/IP over
sockets in VW.  I've used VW sockets for a few things including the
PostgreSQL drivers (as a TCP/IP client) and the Swazoo HTTP server (as
a TCP/IP server).

As it happens, I always now use sockets through the Sport library
SpSocket class and friends, so I get to write code that works
unaltered in a number of Smalltalk implementations.  This also means I
get to fiddle with socket classes in several Smalltalks when I port
Sport.

What started me on this thread is that a previously reliable piece of
code went into a loop.  By reliable, I mean this code has been running
in a server for years without problem.  The loop was:

  o Me:  Socket, do you have any data for me?
  o Socket: Why, yes I do!
  o Me: Gosh, thanks.  Let me have all those lovely bytes so I can process them.
  o Me: Wow, I go through all those bytes quickly, now to see if more
have come in
 <repeat>

If there was no data, I would have expected the socket to tell me
that.  If the socket had failed, I expected an exception.  I got
neither.

Then, when I asked about it on this list, Martin said that this
situation was quite normal and indicated that the socket had been
disconnected at the remote end.

See top of thread ... (I hope you don't end up in a loop too!)

> As said above I do not think the current interface is an "interpretation" of
> the interface between VM and image.

Right.  I see that you are saying that the classes reflect the
implementation in the VM.  I'm pointing out (is response to Martin's
"interpretation" point) that they are not a 1-1 mapping of the BSD
socket library.  I know  the BSD socket library  is not a solid target
(i.e. variations in Linux & WIndows), but the classes available to VW
programmers could be much closer.

And given the VW classes the are an "interpretation" (and they are),
they may as well be a useful one.

...

I think, perhaps, the best way to pursue this thread would be over a
beer at StS.  I have a work-around in Sport now, and so have no
immediate problem.  The issue  at this point is that people new to
sockets would be surprised by the current behaviour (assuming they use
the VW sockets directly rather than working through Sport ... which
*is* an interpretation, but at least a sane one ... from my pov :-)).

All the best,
    Bruce
--
Make the most of your skills - with OpenSkills
http://www.openskills.org/