enhancement request: SocketStream

Here's another enhancement request -- or possibly it's a bugfix request.

I'm being bugged by the amount of special-case code I have to write to deal
with EOF on a readstream from a socket.  Code deep in my application that
shouldn't have to know that its talking to a socket stream has to catch and
handle this socket-specific error.

Normal networking errors I -- obviously -- have to deal with, but they are
better handled at a higher level in my app.  EOF, however, is part of the
normal process of reading a stream (whether it be connected to a file, pipe,
or socket).  As it currently stands none of #do:, #contents, or an
#atEnd/#whileFalse: loop work.

I imagine that #atEnd can't be made reliable, since it's impossible to tell
whether an underlying socket which has no data available at one instant will
be closed at the next instant or given more data.  However I think that
makes it more important for socket stream to have to have its own
implementations of #collect: and #do: (both of which *can* be implemented
without that problem).

The socket stream code contains a few #todo-s.  I don't know what priority
you (OA) have given to implementing them, but unless it's high already, may
I ask you to increase it please ?

    -- chris

I wrote:

> makes it more important for socket stream to have to have its own
> implementations of #collect: and #do:

Argh!!  I *meant* #contents and #do:

Sorry for any confusion.

    -- chris

Chris,

> > makes it more important for socket stream to have to have its own
> > implementations of #collect: and #do:
>
> Argh!!  I *meant* #contents and #do:
>
> Sorry for any confusion.

It looks like I'm not seeing all of the posts - or is this a reply to
something old??  With the caveat that I'm jumping in blind, there's a
problem with #contents for a stream that's potentially "bottomless", like a
socket, because the answer one gets might change at moment (the number of
available bytes can grow asyncrhonously as new data arrives).  Generally, I
try to know how much data I need to read, and block for that much (on a
background thread, of course).  For binary streams that don't leave room for
a terninating byte, I send the number of bytes to expect followed by the
bytes; that can be done any number of times until the socket is closed or
until a command arrives.  Text protocols are often easier, because you can
just grab what's available, and take action only when you see the
terminator.

Does that help?  Any counter examples or better ideas?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

> It looks like I'm not seeing all of the posts - or is this a reply to
> something old??

Hmm, that's worrying.  The two posts were about 20 minutes apart.  Has
the first one reached you by now ?

It wasn't long so I'll quote it again at the end of this message.

>  With the caveat that I'm jumping in blind, there's a
> problem with #contents for a stream that's potentially "bottomless",
like a
> socket

Yes, you've guessed (part of) the subject spot on.  A cigar to the
gentleman in the white coat!

Things like #contents *can* be missused with streams.  E.g. doing it on
a TCP/IP connection from an NNTP server would be meaningless, but it's
perfectly appropriate in other circumstances -- talking HTTP 1.0, or
doing a TCP DNS lookup, for example.  It all depends on the nature of
the higher-level protocol.

> Bill

======= Original post which seems to be missing at sea ========

Here's another enhancement request -- or possibly it's a bugfix request.

I'm being bugged by the amount of special-case code I have to write to
deal
with EOF on a readstream from a socket.  Code deep in my application
that
shouldn't have to know that its talking to a socket stream has to catch
and
handle this socket-specific error.

Normal networking errors I -- obviously -- have to deal with, but they
are
better handled at a higher level in my app.  EOF, however, is part of
the
normal process of reading a stream (whether it be connected to a file,
pipe,
or socket).  As it currently stands none of #do:, #contents, or an
#atEnd/#whileFalse: loop work.

I imagine that #atEnd can't be made reliable, since it's impossible to
tell
whether an underlying socket which has no data available at one instant
will
be closed at the next instant or given more data.  However I think that
makes it more important for socket stream to have to have its own
implementations of #collect: and #do: (both of which *can* be
implemented
without that problem).

The socket stream code contains a few #todo-s.  I don't know what
priority
you (OA) have given to implementing them, but unless it's high already,
may
I ask you to increase it please ?

    -- chris

Bill,

Re-reading your post, and immediately after sending a reply to it
(sigh...), something else occurred to me.

>... there's a
> problem with #contents for a stream that's potentially "bottomless",
like a
> socket, because the answer one gets might change at moment (the number
of
> available bytes can grow asyncrhonously as new data arrives).

It might not be obvious that I'd expect SocketReadStream>>contents to
block until the socket has been closed, and then answer all the data
read from the socket.  Not just to answer the data which is available at
that instant.

Exactly the same semantics as a FileReadStream, in fact, just read up to
EOF and answer the lot.  (And god help you if it was a 1.5 GByte
file...)

    -- chris