Re: Networking with CL


"Alex Mizrahi" <udodenko@xxxxxxxxxxxxxxxxxxxxx> writes:

yes, i think so. as you see, abstraction that is good for TCP
(streams) is not good even for it's socket brother UDP. what's
about other network protocols and architectures?

Streams are actually a lousy abstraction for reading from a network
socket. The abstraction does work cleanly for writing, however.

When reading, you really want to say to the system "please start
reading data from this socket until a fully formed data blob has been
read, and then call this function with the blob."

Of course the meaning of "fully formed data blob" is dependent on the
protocol you're reading. For HTTP it's \r\n\r\n or something like
that. You might have a fixed length message coming at you. Or one
can imagine a header/body protocol with a fixed length header telling
you how many bytes are in the body. Etc.

You can do all of this with a stream interface, except then you're
forced to use threads, because for many protocols you don't know how
much data you need to read, so you have to block[1]. I find debugging
threaded programs much more difficult than non-threaded programs, so I
think this is a serious disadvantage for using streams to read from
sockets.

Also, one thread per client has kind of sucky resource requirements,
compared to just using poll / kqueue / epoll / IOCP or what have you.

I mention all of the above, because I'm just finishing up an interface
to the poll(2) system call for sbcl. Let me know if you want to see
it...

also note that different people want to work with networking at
different abstraction level: some people are satisfied with streams,
other people would like to modify IP headers on packet level.

Or maybe threads are just too hard, let's go shopping...

and all this stuff is highly system-dependent.. event
demultiplexing, for example. should they make all networking doomed
to be synchonous, or require implementors to implement ``select'' on
systems which do not support it?

Keep in mind that this type of IO is only available on MacOS, BSD,
Linux, Solaris, AIX, and Windows. Oh wait, I'm probably forgetting a
few.

-russ

[1] I'm aware of CMUCL's recursive event loop that hides the blocking.
It's a nice hack, but IMHO it's a heroic attempt to pound a square peg
into a round hole.
.

Relevant Pages

  • Re: SCTP using questions (API etc.)
    ... How long can be one particular SCTP message? ... You do not have to deal with the recv buffer ... size of the send socket buffer.. ... What is the minimum number of streams application can rely ...
    (freebsd-net)
  • Re: Cracking ConfigurationManager
    ... My experience with VB6 is that it makes easy things ... Reading and writing to a text file ... you'd have to parse the .config file as an XML ... files (streams) on disk, then it is a relatively TRIVIAL effort to ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: [PATCH 4/6] sctp multistream scheduling: extend socket API
    ... The choice and configuration of the scheduling algorithm is still ... declaring the socket but before association establishment. ... socket option is set, the configurations are stored in sctp_sock. ... If the negotiated number of streams is smaller that what the user ...
    (Linux-Kernel)
  • Re: Cracking ConfigurationManager
    ... But to be accurate about this particular situation (reading App.config), we aren't just reading and writing to a text file. ... But once you "get it" and can work with files (streams) on disk, then it is a relatively TRIVIAL effort to generalize that knowledge to reading and writing across the wire - even encrypting your communications. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: [PATCH 4/6] sctp multistream scheduling: extend socket API
    ... The choice and configuration of the scheduling algorithm is still ... declaring the socket but before association establishment. ... just as easily queue it to the socket as to the association. ... If the negotiated number of streams is smaller that what the user ...
    (Linux-Kernel)