Squeak listening to specific IP Addresses?
andreas.raab at gmx.de
Thu Jan 22 19:31:07 UTC 2004
> There are two issues: compatibility to old images, and compatibility to
> MacOS classic. Old images use the old primitives, including the strange
> listenOn: primitive which closes the listening socket after the first
> connection. Granted, it has been a few years at this point. As a
> bigger issue, there was a problem using BSD sockets on MacOS classic.
> That's why Squeak has its distinctive sockets API to begin with...
Well, I don't think that's actually true - IIRC, then the reason for the
socket interface was that the BSD sockets weren't the default on classic
MacOS (I think it used to be third party). And since classic MacOS had a few
very specific idiosynchracies, the interface reflects some of them to the
extend that one would expect.
> That aside, let's go whole hog! Make a real BSDSocket class that has
> all the functions BSD sockets are supposed to have. To get an idea of
> what is required, download Scheme Shell and look what they did; I have
> heard they have a quite thorough wrapper for BSD sockets into Scheme,
> plus some nice utilities sitting on top of them.
I tried that but the one thing I couldn't find and the only one thing that
I'd be really interested in is how they deal with the equivalent to select()
and friends. That's probably the only place where it gets interesting.
> Keep in mind that there are probably a lot of odds and ends that the
> current primitives overlook. For example, there is out of band data
> that would be useful for a proper telnet client. There are also various
> flags in some of the functions that we are probably overlooking.
Certainly so, but realistically, I don't care too much about them. Quite to
the contrary to be honest - my feeling is that various of the options we
specify today can (and should) be set via options instead of having them
inside some primitive or other. For example, it seems that the send and
receive buffer size should be specified that way and looking at
primSocket:setPort: just makes me want to puke.
> Anyway, I am not volunteering any effort here, so do as ye will. :) It
> just worries me to see this endless tinkering. Either we want
> super-portable primitives like the original Squeak primitives, or we
> want to insist on full BSD semantics. Playing around in the between
> spaces seems strange.
Not at all. "This endless tinkering" is supposed to come up with a balanced
POV between what primitives are supposed to do vs. what the Smalltalk code
needs to deal with and how it affects compatibility issues. I wouldn't see
the distinction as hard as you make it here - to me it seems quite
reasonable to discuss these issues and get an understanding of how we would
want to deal with them at minimal cost. Given what has been said sofar, it
seems that we may get away with relatively few changes which effectively
comes down to providing an interface to bind() as well as a "pure" interface
to listen() (e.g., one which doesn't take a port) but this could be easily
"simulated" by specifying port zero. Exposing bind() addresses the issues at
hand and would - a little further down the road - allow us to address some
of the other issues.
More information about the Squeak-dev