Squeak listening to specific IP Addresses?

Lex Spoon lex at cc.gatech.edu
Thu Jan 29 23:39:13 UTC 2004

"Andreas Raab" <andreas.raab at gmx.de> wrote:
> > 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.

Yes, exactly what I said.  :)  Glad to hear things are better nowadays
in the Mac world.

Note, by the way, that we are talking about a situation where Apple
designed their own interface.  Squeak people had trouble using this
interface, even though it seemed logical if you read the docs. 
Nowadays, Apple seems to be using BSD sockets, along with BSD-ish almost
everything else.

> > 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.
> >
> > http://www.scsh.net
> 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.

It's in 3.2.6 of the manual.  It's called "Unix I/O".  If I read
correctly, there is a "select" function that takes as arguments three
lists of "ports", where each "port" is either a scheme-level I/O entity
or is a wrapper around a low-level thing such as a socket.  Thus sockets
and files and scsh's equivalent of ReadStream can all be passed in to

Dunno how it works under the hood, but the "port" data type is probably
where to start digging.  I'm sure we'd all LOVE to have such a thing in

> > 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.

Well, someone must care about them. :)  Everything in BSD sockets is
there because someone had a use for it.

> > 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 am completely baffled.  If you want a portable network interface, then
that's what BSD sockets is.  If you want a good interface between user
code and system code, again, BSD sockets is a well defined standard.

Thus, if you really really want to play with this, then I look forward
to seeing what you come up with.  But if you and no one else is really
up for it, it seems like a good idea to go with the existing solution.

> Given what has been said sofar, it
> seems that we may get away with relatively few changes[...]

Well that's good to hear.  You still can't do a proper telnet in Squeak,
but it is always nice to tick off one more useful feature.


More information about the Squeak-dev mailing list