[Cc to Duane Rettig: I'd be glad for corrections if I misrepresented
your words or acl in any way]
Daniel Barlow <dan@...> writes:
> Allegro's simple-streams interface includes a class called
> simple-socket-stream. However, it looks from the Allegro sockets
> documentation that the user is not expected to create socket-streams
> directly, but instead to call make-socket and let it select the
> appropriate subtype. That being so, I think the fact that their
> sockets are simple-streams is largely an implementation detail for
> So it seems that the directly instantiable simple-socket-stream class
> we have in sbcl contrib is a bonus. And what a lovely bonus. Here's
> the test case -
> (with-open-stream (s (make-instance 'socket-simple-stream
> :remote-host #(127 0 0 1)
> :remote-port 7))
> (string= (prog1 (write-line "Got it!" s) (finish-output s))
> (read-line s)))
> (sb-bsd-sockets::connection-refused-error () t))
IIUC, Allegro's make-socket opens the socket itself, then passes the
fd to make-instance of socket-simple-stream, but that's an
implementation artifact and not part of some protocol.
I asked Duane Rettig about the proper protocol for obtaining a socket
stream. He replied that (paraphrased) Allegro's socket implementation
carries some baggage from its Gray days, and that make-socket does
some work that could be handled by make-instance of socket stream.
Excerpt from the email exchange:
Rudi> (More generally, does the simple-stream protocol allow
Rudi> arbitrary options for make-instance / device-open?)
Duane> Yes, in fact that is the intended way for device-open options to
Duane> be specified. It is as if the make-instance/reinitialize-instance
Duane> were defined with &allow-other-keys, so that device-open can receive
Duane> options itself.
That's how the :remote-host and :remote-port options to device-open
for socket-simple-streams came to be, even though they're not in the
Franz simple-streams documentation. I think any hairy socket options
can be passed down to device-open by that route.
> I think this is a thoroughly good thing and should be adopted as the
> basis of a high(er)-level socket interface in SBCL. I propose
> 1) a new class for each address family (internet, local-domain, ip
> version 6, decnet, chaosnet, etc). No, I'm not necessarily
> suggesting we need to implement all of these.
> 2) keyword arguments to the constructor for each of these that more or
> less follows the shape of Perl's IO::Socket::Foo modules
> (modulo using complete words and hyphens instead of StudlyCaps)
> (make-instance 'inet-socket :peer-host "www.google.com" :peer-port 80
> :protocol :tcp :type :stream :multihomed t)
> I can't put this stuff in sb-bsd-sockets as it currently stands
> because sb-simple-streams depends on it for the existing
> simple-socket-stream, and that would be circular. I don't think
> they're logically part of the simple-streams interface either, though.
> Can we lose simple-socket-stream as it currently stands (it could
>become the base class for these protocol family streams) if we get
>this stuff instead? Or should I add an SB-SOCKET-STREAMS contrib?
>That's a possibility, but I'm not sure it wins us anything useful
I'd say go the simple-streams route, but then I would. ;)
As I see it, there's two parts of this:
- Create something that's a source / sink of a stream of bytes.
For files, there's sb-unix:unix-open, sb-bsd-sockets provides opened
socket fds, etc.
- Implement Lisp-stream semantics for that object, provide buffering.
Simple-streams does this.
Would it work to extend device-open for socket-simple-streams with
additional initargs instead of constructing a class hierarchy?
:protocol :chaosnet :funky-chaosnet-option 42
That is, as long as (device-open socket-simple-stream) can glean from
the passed options what type of byte source / sink to obtain from
sb-bsd-sockets, the socket-simple-stream class machinery should work
with all of them.
Server sockets and, perhaps, datagram sockets are another topic:
server sockets aren't streams, and I'm not sure if seeing a udp socket
as a stream is the right thing.
whois DRS1020334-NICAT http://constantly.at/pubkey.gpg.asc
Key fingerprint = C182 F738 6B9A 83AF 9C25 62D9 EFAE 45A6 9A69 0867