Hi,
Is it possible to configure Squeak to listen to specific IP Addresses and Ports, i.e. 1.2.3.4:8000, on a machine that supports multiple ip addresses? If so how? If not, how can we add this feature?
A further example is running a Comanche squeak server on 1.2.3.4:80 and on 5.6.7.8:80.
Two basic configurations interest me.
1. Restrict a squeak image to a specific ip address (or more than one specific address) from the set of addresses that are being homed on the server.
2. Enable squeak to listen to specific ipa:port pairs from the set of addresses that are being homed on the server.
All the best,
Peter William Lount, Smalltalk.org Senior Editor peter@smalltalk.org peter@activeinfo.ca
This should lurk in the macintosh and unix ports, can't speak for the windows port. Not sure if the smalltalk code needed to invoke the primitive is in the image, check the archives.
On Jan 19, 2004, at 1:10 PM, Peter William Lount wrote:
Hi,  Is it possible to configure Squeak to listen to specific IP Addresses and Ports, i.e. 1.2.3.4:8000, on a machine that supports multiple ip addresses? If so how? If not, how can we add this feature?  A further example is running a Comanche squeak server on 1.2.3.4:80 and on 5.6.7.8:80.  Two basic configurations interest me.
- Restrict a squeak image to a specific ip address (or more than one
specific address)Â from the set of addresses that are being homed on the server. Â 2. Enable squeak to listen to specific ipa:port pairs from the set of addresses that are being homed on the server. Â All the best, Â Peter William Lount, Smalltalk.org Senior Editor peter@smalltalk.org peter@activeinfo.ca
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
This should lurk in the macintosh and unix ports, can't speak for the windows port.
I committed the relevant code today ;-)
Cheers, - Andreas
On Jan 19, 2004, at 1:10 PM, Peter William Lount wrote:
Hi,
Is it possible to configure Squeak to listen to specific IP Addresses and Ports, i.e. 1.2.3.4:8000, on a machine that supports multiple ip addresses? If so how? If not, how can we add this feature?
A further example is running a Comanche squeak server on 1.2.3.4:80 and on 5.6.7.8:80.
Two basic configurations interest me.
- Restrict a squeak image to a specific ip address (or more than one
specific address) from the set of addresses that are being homed on the server.
- Enable squeak to listen to specific ipa:port pairs from the set of
addresses that are being homed on the server.
All the best,
Peter William Lount, Smalltalk.org Senior Editor peter@smalltalk.org peter@activeinfo.ca
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
Peter William Lount wrote:
Hi,
Is it possible to configure Squeak to listen to specific IP Addresses and Ports, i.e. 1.2.3.4:8000, on a machine that supports multiple ip addresses? If so how? If not, how can we add this feature?
A further example is running a Comanche squeak server on 1.2.3.4:80 and on 5.6.7.8:80.
Two basic configurations interest me.
- Restrict a squeak image to a specific ip address (or more than one
specific address) from the set of addresses that are being homed on the server.
- Enable squeak to listen to specific ipa:port pairs from the set of
addresses that are being homed on the server.
All the best,
Peter William Lount, Smalltalk.org Senior Editor peter@smalltalk.org mailto:peter@smalltalk.org peter@activeinfo.ca mailto:peter@activeinfo.ca
I've got Squeak running on a multi-homed machine. However...
...it listens on a given port, regardless of which IP any given request targeted. So, this implies that the answer to both of your questions is "NO".
However...
...it's not hard to have a given image subsequently "throw away" requests that weren't directed at a specific IP. So, this implies that the answer to both of your questions is "YES".
What you CANNOT do, is have two separate images each listening on the same port.
A further example is running a Comanche squeak server on 1.2.3.4:80 and on 5.6.7.8:80.
If you mean to say: one image listening on port 80, on a machine that is multi-homed at IP addresses 1.2.3.4 and 5.6.7.8, then "YES".
If you mean to say: two different images, one listening on 1.2.3.4:80, and the other listening on 5.6.7.8:80, then "NO"
Here is another example:
One image can listen on port 80, and "throws away" requests that weren't directed to IP 1.2.3.4, thus it is "listening" only to 1.2.3.4:80.
Another image running on the same machine listens to port 8080, and "throws away" requests that weren't directed to IP 5.6.7.8, thus it is "listening" only to 5.6.7.8:8080.
The two images can even forward requests back-and-forth to each other (and thus serve as a network bridge between the two IP's).
But they can't both be listening on port 80. That won't work.
Nevin
[ENH] Binding Sockets to specific interfaces (resend) Date: December 5, 2003 12:16:54 PM PST A note from Andreas, which means the windows support must be there,. Note of VM Support in 3.7a VMMaker change Change set: OldSocket methodsFor: 'primitives' stamp: 'ikp 9/1/2003 20:55'! primSocket: aHandle listenOn: portNumber backlogSize: backlog interface: ifAddr
---------------- From: ian.piumarta@inria.fr Subject: Re: How to bind a listening socket to an address? Date: September 1, 2003 12:41:02 PM PDT The required primitive is now in my 3.6-beta9 Unix VMs, source and binaries
------------------ Yes, also in the 3.7.x macintosh carbon VMs... ---------------------------
On Jan 19, 2004, at 4:45 PM, Nevin Pratt wrote:
I've got Squeak running on a multi-homed machine. However...
...it listens on a given port, regardless of which IP any given request targeted. So, this implies that the answer to both of your questions is "NO".
However...
...it's not hard to have a given image subsequently "throw away" requests that weren't directed at a specific IP. So, this implies that the answer to both of your questions is "YES".
What you CANNOT do, is have two separate images each listening on the same port
--
======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
Hi,
Thanks for the assistance.
1) Listening to Specific IP Addresses Socket (and OldSocket) have a method that activates a primitive to listen on a specific IP Address and Port pair:
OldSocket >>primSocket: aHandle listenOn: portNumber backlogSize: backlog interface: ifAddr Socket>>primSocket: aHandle listenOn: portNumber backlogSize: backlog interface: ifAddr
This seems to enable the listening of connections for "incoming" conversations providing the ability to run multiple instances of a service on the same port but with different ip addresses. i.e. 1.2.3.4:80 and 5.6.7.8:80.
Excellent.
2) Connecting From Specific IP Address (and Port) Socket>>primSocket: socketID connectTo: hostAddress port: port
There doesn't seem to be a way to initiate an "outgoing" connection FROM a particular IP Address on a multi-homed computer. You can choose the address and port of the destination for the connection but you can't choose the from/source ip address (and port). The address likely defaults to the computer's default address. This is fine when there is one ip address but when the computer has multiple ip addresses (i.e. multi-homed) it is a problem, especially when it's important to use particular ip addresses for particular purposes (i.e. logging, bandwidth tracking, web servers, etc...).
In a full socket protocol you can specify both "source ipaddress:port" and "destination ipaddress:port" pairs for outgoing connections. I propose that we extend the Squeak primitives (as follows) to support this full protocol.
"All selection of the outgoing ip address to use. Allow system to choose outgoing port." Socket>> primSocket: socketID connectTo: destinationAddress port: destinationPort connectFrom: sourceAddress
Obviously the source address MUST be one of the ip addresses that the local computer is currently assigned. As such this method really only makes sense on multi-homed computers. This shouldn't allow "spoofing" of the sending ip address.
"Allow selection of the outgoing ip address to use. In addition request the outgoing port to use." Socket>> primSocket: socketID connectTo: destinationAddress port: destinationPort connectFrom: sourceAddress port: sourcePort
Generally you don't care which outgoing port is used (as it might be in use already) so the first method is used more often.
Obviously we'd need the non-primitive methods as well.
Does any version of squeak have these or equilivant primitives?
What do you think? I definitely need to have the ability to choose the outgoing ip address since they are assigned for particular purposes.
All the best,
Peter William Lount, Smalltalk.org Senior Editor peter@smalltalk.org peter@activeinfo.ca
p.s. Would it be possible to add my email alias peter@activeinfo.ca to be accepted by the squeak list? I already receive the list to peter@smalltalk.org but sometimes I send from the alternate email address.
Hi Guys,
Someone with a bit more socket knowledge should chime in here but it seems to me that this almost cries for a primitive doing the equivalent to BSD's bind() call - e.g., assign a local address and port to a socket. So wouldn't it be easier just to expose something like:
Socket>>bindTo: localAddress port: localPoirt
rather than trying to put all of this information in all of the varying places?
Cheers, - Andreas
----- Original Message ----- From: "Peter William Lount" peter@ActiveInfo.CA To: "Squeak Developers" squeak-dev@lists.squeakfoundation.org Sent: Tuesday, January 20, 2004 7:58 PM Subject: Re: Squeak listening to specific IP Addresses?
Hi,
Thanks for the assistance.
- Listening to Specific IP Addresses
Socket (and OldSocket) have a method that activates a primitive to listen
on
a specific IP Address and Port pair:
OldSocket >>primSocket: aHandle listenOn: portNumber backlogSize: backlog interface: ifAddr Socket>>primSocket: aHandle listenOn: portNumber backlogSize: backlog interface: ifAddr
This seems to enable the listening of connections for "incoming" conversations providing the ability to run multiple instances of a service on the same port but with different ip addresses. i.e. 1.2.3.4:80 and 5.6.7.8:80.
Excellent.
- Connecting From Specific IP Address (and Port)
Socket>>primSocket: socketID connectTo: hostAddress port: port
There doesn't seem to be a way to initiate an "outgoing" connection FROM a particular IP Address on a multi-homed computer. You can choose the
address
and port of the destination for the connection but you can't choose the from/source ip address (and port). The address likely defaults to the computer's default address. This is fine when there is one ip address but when the computer has multiple ip addresses (i.e. multi-homed) it is a problem, especially when it's important to use particular ip addresses for particular purposes (i.e. logging, bandwidth tracking, web servers,
etc...).
In a full socket protocol you can specify both "source ipaddress:port" and "destination ipaddress:port" pairs for outgoing connections. I propose
that
we extend the Squeak primitives (as follows) to support this full
protocol.
"All selection of the outgoing ip address to use. Allow system to choose outgoing port." Socket>> primSocket: socketID connectTo: destinationAddress port: destinationPort connectFrom: sourceAddress
Obviously the source address MUST be one of the ip addresses that the
local
computer is currently assigned. As such this method really only makes
sense
on multi-homed computers. This shouldn't allow "spoofing" of the sending
ip
address.
"Allow selection of the outgoing ip address to use. In addition request
the
outgoing port to use." Socket>> primSocket: socketID connectTo: destinationAddress port: destinationPort connectFrom: sourceAddress port: sourcePort
Generally you don't care which outgoing port is used (as it might be in
use
already) so the first method is used more often.
Obviously we'd need the non-primitive methods as well.
Does any version of squeak have these or equilivant primitives?
What do you think? I definitely need to have the ability to choose the outgoing ip address since they are assigned for particular purposes.
All the best,
Peter William Lount, Smalltalk.org Senior Editor peter@smalltalk.org peter@activeinfo.ca
p.s. Would it be possible to add my email alias peter@activeinfo.ca to be accepted by the squeak list? I already receive the list to peter@smalltalk.org but sometimes I send from the alternate email address.
Hi Andreas,
On 20 Jan 2004, at 20:41, Andreas Raab wrote:
Someone with a bit more socket knowledge should chime in here but it seems to me that this almost cries for a primitive doing the equivalent to BSD's bind() call - e.g., assign a local address and port to a socket. So wouldn't it be easier just to expose something like:
Socket>>bindTo: localAddress port: localPoirt
rather than trying to put all of this information in all of the varying places?
This is already _precisely_ what aSock listenOnPort: aPort backlogSize: nConn interface: anAddr does. Cutting out the irrelevant implementation noise, the body of the prim contains
saddr.port = aPort; saddr.addr = anAddr; bind(aSock, saddr); listen(aSock, nConn);
(nothing more, nothing less). IOW, the only difference between the prim and bind() is that the prim goes on to perform the listen() as well, since you're pretty much guaranteed to want to do that after binding the address.
FWIW, the only difference between that and the "old" listenOn: primitive is that the old one uses INADDR_ANY for the interface address (which causes the socket to be bound to the given port on all available local interfaces).
Cheers, Ian
Hi Ian,
This is already _precisely_ what aSock listenOnPort: aPort backlogSize: nConn interface: anAddr does.
Yes, I understand this - I was more thinking along the lines of actually simplifying the listen primitive(s) so that the ST side would look along the lines of:
listenOn: port backlogSize: count interface: ipAddr
self bindTo: ipAddr port: port. self listen: backlogSize.
etc. So #bindTo:port: would handle all the aspects that are now done in the primitive and listen primitive would just listen on the locally assigned address - which means that the socket prims actually model the underlying BSD socket semantics much more closely, are easier to implement and probably a bit easier to use.
(nothing more, nothing less). IOW, the only difference between the prim and bind() is that the prim goes on to perform the listen() as well, since you're pretty much guaranteed to want to do that after binding the address.
Not if you want to use a specific local interface in a connect() call (that was the starting point for the discussion). In general I think it's advantageous to model the Squeak primitives to closely resemble the BSD sockets interface just on the general grounds of simplifying the VM implementation. So that - #primitiveConnect has the semantics of connect() - #primitiveListen has the semantics of listen() - #primitiveBind has the semantics of bind() etc.
Cheers, - Andreas
Hi Andreas,
Not if you want to use a specific local interface in a connect() call (that was the starting point for the discussion).
Conceded.
In general I think it's advantageous to model the Squeak primitives to closely resemble the BSD sockets interface just on the general grounds of simplifying the VM implementation.
No disagreement there, assuming John wouldn't have to rewrite a bunch of really stale and ugly Mac prims to cope...
Ciao, Ian
Hi Ian,
In general I think it's advantageous to model the Squeak primitives to closely resemble the BSD sockets interface just on the general grounds of simplifying the VM implementation.
No disagreement there, assuming John wouldn't have to rewrite a bunch of really stale and ugly Mac prims to cope...
For bind(), connect() and listen() I wouldn't expect this to be a problem. All a bind primitive implementation would do is to remember the address+port for the socket. Then, upon connect or listen primitive it may decide to use only an address that's equivalent with localHostAddress and otherwise fail. This behavior would be precisely equivalent with that of a machine with a single interface and not require much extra effort.
Given the other discussion with David, how about starting to work on a SocketPlugin v2 which contains these as well as some of the stuff David was proposing? E.g., this could then also support IPv6, interface enumeration etc. etc. etc.
Cheers, - Andreas
Andreas Raab wrote:
Given the other discussion with David, how about starting to work on a SocketPlugin v2 which contains these as well as some of the stuff David was proposing? E.g., this could then also support IPv6, interface enumeration etc. etc. etc.
This is a very very good point. There was much talk about IPv6 in the last days by several companies. I would like to see this. And I would like if it is BSD-Style.
regards Chris Burkert
Given the other discussion with David, how about starting to work on a SocketPlugin v2 which contains these as well as some of the stuff David
was
proposing? E.g., this could then also support IPv6, interface enumeration etc. etc. etc.
- Andreas
Hi,
Interface enurmeration seems important to my needs as well. This way a program can, amoung many possible purposes, discover if it has access to the interfaces that it's been configured for.
Thanks,
peter
On Jan 20, 2004, at 12:40 PM, Ian Piumarta wrote:
In general I think it's advantageous to model the Squeak primitives to closely resemble the BSD sockets interface just on the general grounds of simplifying the VM implementation.
No disagreement there, assuming John wouldn't have to rewrite a bunch of really stale and ugly Mac prims to cope...
Ciao, Ian
This is not a problem the old os-9 open transport code currently does as an example.
OTInitInetAddress(&epi->localAddress, 0, kOTAnyInetAddress);
which is part of the DoBind() procedure which binds the connection (like like a socket) to the remote and local sides.
If you pass in the port, and the interface address we'll use that instead of the 0, and kOTAnyInetAddress {meaning any interface address}
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
Not if you want to use a specific local interface in a connect() call (that was the starting point for the discussion).
Conceded.
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...
But I would guess neither of these is a big deal.
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.
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.
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.
-Lex
On Jan 22, 2004, at 9:02 AM, Lex Spoon wrote:
Not if you want to use a specific local interface in a connect() call (that was the starting point for the discussion).
Conceded.
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...
Lex that's not quite true, since May of 2000 the classic Mac VM has used Open Transport which supports the listen properly. I think at Smalltalk Solutions a few years back there was interest in doing a BSD socket like layer...
--
======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
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.
Cheers, - Andreas
"Andreas Raab" andreas.raab@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.
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 select.
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 Squeak.
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.
-Lex
Flow ( http://netjam.org/flow ) has a straightforward primitive interface to BSD sockets (and a framework for files, MIDI, etc.), and would be a fine starting point for things like supporting multiple NICs, out-of-band data, etc.
-C
-- Craig Latta improvisational musical informaticist craig@netjam.org www.netjam.org [|] Proceed for Truth!
Hi,
Has any progress on squeak's interface to BSD sockets been made? Was anyone taking this on?
Cheers,
peter
Hi Peter--
Has any progress on squeak's interface to BSD sockets been made? Was anyone taking this on?
I'm not aware of any new socket features being added since you last asked. I think the Flow framework ( http://netjam.org/flow ) is the best starting point for this work, since it has had a BSD orientation toward sockets from the beginning (and this is reflected in a more straightforward primitive interface).
I currently don't have any need myself for multiple NIC support, out-of-band data, etc. However, I plan to add these things to Flow (if someone else hasn't already) after the current push on Squat (my guess is November). In the meantime, please feel free! :)
take care,
-C
-- Craig Latta improvisational musical informaticist craig@netjam.org www.netjam.org [|] Proceed for Truth!
Craig Latta wrote:
Hi Peter--
Has any progress on squeak's interface to BSD sockets been made? Was anyone taking this on?
I'm not aware of any new socket features being added since you last asked. I think the Flow framework ( http://netjam.org/flow ) is the best starting point for this work, since it has had a BSD orientation toward sockets from the beginning (and this is reflected in a more straightforward primitive interface).
From browsing it looks like Flow is still Alpha. Has it been tried in a 3.7 image?
I read your comparison between Flow and Squeak's sockets. Its an older article. Is it still accurate concerning Squeak's socket rewrite?
Spelunking in Squeak's Socket code leaves me scratching my head. We have Socket, OldSocket, SocketStreams, OldSimpleClientSocket... I know two of those are sub-classes.
I might misunderstand what I see, I am far from knowledgeable. But it seems like Squeak's socket situation could use some consolidation.
And where does Flow fit into the above? How well does Flow perform? Would web apps be improved with Flow? How hard to migrate to Flow?
Just some naive questions.
Thanks.
Jimmie Houchin
Hi Jimmie--
From browsing it looks like Flow is still Alpha.
I'd call it final at this point, no problems in the last two years.
Has it been tried in a 3.7 image?
I'm using it in a 3.6.5424 snapshot, which I think is equivalent as far as this stuff goes.
I read your comparison between Flow and Squeak's sockets. Its an older article. Is it still accurate concerning Squeak's socket rewrite?
The primitive interface hasn't changed, so all those comments still apply.
Spelunking in Squeak's Socket code leaves me scratching my head. We have Socket, OldSocket, SocketStreams, OldSimpleClientSocket... I know two of those are sub-classes.
I might misunderstand what I see, I am far from knowledgeable. But it seems like Squeak's socket situation could use some consolidation.
Yes. :)
And where does Flow fit into the above?
I think the Flow advocacy page still makes that case well ( http://netjam.org/flow/advocacy.html ). Basically, it replaces a lot of messy and broken stuff. There was some resistance before about the cost of adapting applications to it, but, to me, the "socket rewrite" experience shows that there's not much one can do about that. :) Also, adapting applications that already use stream interfaces (e.g., those that use Michael's work)
How well does Flow perform?
What terms are meaningful to you? It performs very well in my own work (as fast as is possible with each host OS, I suspect). From a theoretical standpoint I think it should perform better than the official stuff (see the advocacy page again), but I haven't done a thorough benchmark comparison.
Would web apps be improved with Flow?
They would be easier to write and understand (these are the things I see as the main benefits of the design).
How hard to migrate to Flow?
It isn't hard. Writing applications to use streams instead of explicit collection copying is much easier, actually. And adapting applications that already use streams (e.g., those that use the "socket rewrite") is pretty easy.
To some degree, having a system based on a minimal snapshot makes this issue moot (which was part of my motivation for developing the minimal system :). There can be any number of socket frameworks; they'll just be modules which can be loaded and unloaded at whim. In the particular case of Flow, it coexists with the other two socket frameworks (since it uses a dynamically loadable virtual machine plugin for its primitives), so I don't see any great need for there to be One True Socket Framework. :) I do think, though, that Flow is the easiest to use, which is why I advocate it.
Also keep in mind that Flow does more than sockets (files, MIDI, speech, etc.), and it does all that stuff in a consistent way, which is nice.
thanks,
-C
-- Craig Latta improvisational musical informaticist craig@netjam.org www.netjam.org [|] Proceed for Truth!
Oh, and as I believe I've mentioned here a few times, I want the next release of Flow to take the form of a Squat module, loaded by remote message-sending (into either a minimal snapshot or a conventional pre-4.0 Squeak snapshot). I rather not make any more static-file releases, of anything. :)
-C
-- Craig Latta improvisational musical informaticist craig@netjam.org www.netjam.org [|] Proceed for Truth!
Craig Latta wrote:
Hi Jimmie--
From browsing it looks like Flow is still Alpha.
I'd call it final at this point, no problems in the last two years.
Bueno! I thought it might be stable but wasn't sure due to your definition of alpha.
""" alpha, meaning "this release doesn't implement all the scheduled features". I sometimes add to the current feature list during this stage, but never after (only to the next feature list). """
Has it been tried in a 3.7 image?
I'm using it in a 3.6.5424 snapshot, which I think is equivalent as far as this stuff goes.
Bueno!
I read your comparison between Flow and Squeak's sockets. Its an older article. Is it still accurate concerning Squeak's socket rewrite?
The primitive interface hasn't changed, so all those comments still apply.
Spelunking in Squeak's Socket code leaves me scratching my head. We have Socket, OldSocket, SocketStreams, OldSimpleClientSocket... I know two of those are sub-classes.
I might misunderstand what I see, I am far from knowledgeable. But it seems like Squeak's socket situation could use some consolidation.
Yes. :)
Good.
And where does Flow fit into the above?
I think the Flow advocacy page still makes that case well ( http://netjam.org/flow/advocacy.html ). Basically, it replaces a lot of messy and broken stuff. There was some resistance before about the cost of adapting applications to it, but, to me, the "socket rewrite" experience shows that there's not much one can do about that. :) Also, adapting applications that already use stream interfaces (e.g., those that use Michael's work)
How well does Flow perform?
What terms are meaningful to you? It performs very well in my own work (as fast as is possible with each host OS, I suspect). From a theoretical standpoint I think it should perform better than the official stuff (see the advocacy page again), but I haven't done a thorough benchmark comparison.
That is the answer I was looking for. Basically does it perform better than the Sockets in current use.
Would web apps be improved with Flow?
They would be easier to write and understand (these are the things I see as the main benefits of the design).
Bueno! I think that is of tremendous value.
How hard to migrate to Flow?
It isn't hard. Writing applications to use streams instead of explicit collection copying is much easier, actually. And adapting applications that already use streams (e.g., those that use the "socket rewrite") is pretty easy.
Great! I might have to put my hand to the plow and give it a try.
To some degree, having a system based on a minimal snapshot makes this issue moot (which was part of my motivation for developing the minimal system :). There can be any number of socket frameworks; they'll just be modules which can be loaded and unloaded at whim. In the particular case of Flow, it coexists with the other two socket frameworks (since it uses a dynamically loadable virtual machine plugin for its primitives), so I don't see any great need for there to be One True Socket Framework. :) I do think, though, that Flow is the easiest to use, which is why I advocate it.
I don't believe there is a "requirement" of One True Socket Framework. But I do believe it would be of great benefit. It could/would reduce the effort to understand networking apps. At least that's my view from the outside.
Also keep in mind that Flow does more than sockets (files, MIDI, speech, etc.), and it does all that stuff in a consistent way, which is nice.
Sweeeet!!! :)
I'll give it a download and start learning.
Thanks.
Jimmie Houchin
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.
So we're wanting to develop the SMAlltalk SHell then? I can just see it now:
/usr/local/bin/smash
frank
On Fri, Jan 23, 2004 at 10:50:48AM -0000, Frank Shearar wrote:
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.
So we're wanting to develop the SMAlltalk SHell then? I can just see it now:
/usr/local/bin/smash
Don't laugh, I've already done this and it works reasonably well. Except that I installed it as /usr/local/bin/sqsh, and I like your name much better!
I'll include this next time I put out a CommandShell release, although I've got a lot of changes to merge first. Yes, I know, I need to start using Monticello, which I'm definitely going to do RSN.
Dave
Don't laugh, I've already done this and it works reasonably well. Except that I installed it as /usr/local/bin/sqsh, and I like your name much better!
I'll include this next time I put out a CommandShell release, although I've got a lot of changes to merge first. Yes, I know, I need to start using Monticello, which I'm definitely going to do RSN.
Dave
or /usr/bin/squish
http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-March/054301.htm...
-C
-- Craig Latta improvisational musical informaticist craig@netjam.org www.netjam.org [|] Proceed for Truth!
That's the ticket...
http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-March/054301.htm...
-C
-- Craig Latta improvisational musical informaticist craig@netjam.org www.netjam.org [|] Proceed for Truth!
Hi Andreas,
- #primitiveConnect has the semantics of connect()
- #primitiveListen has the semantics of listen()
- #primitiveBind has the semantics of bind()
etc.
So, you want to do this? I suggest adding one "old-style" primitive in addition (which, along with several older prims, might be culled at some later deadline if backward compatibility goes out the window).
As above, plus:
primConnectTo:interface:
which does primConnect: with an explicit bind() on the socket first. (The reasoning being that it's one method in the image to make it available, keeping everything consistent and compatible with "the old way". From there, given the lower-level prims, you could swap out the guts of Socket to follow a strict BSD model any time you felt like hacking on the image a little. Then if you decide give up on older images, throw the old prims away...)
Ciao, Ian
wouldn't it be easier just to expose something like: Socket>>bindTo: localAddress port: localPoirt
- Andreas
Hi,
I concur. It would be best to mirror the API of the major operating systems network stacks. BSD being the best. ;--)
The UNIX Squeak (version Squeak3.6g-5420 with updates) does not yet have "Socket>>primSocketListenOn:backlog:interface:".
The latest version on http://www-sor.inria.fr/~piumarta/squeak/index.html is Squeak3.6g-5420.image. Is there a newer version with this new primitive? If so, where can I get the latest version of the unix port or the C code updates for it? Or when is a new unix release coming?
All the best,
Peter William Lount, Senior Editor Smalltalk.org peter@smalltalk.org peter@activeinfo.ca
Nevin Pratt wrote:
If you mean to say: one image listening on port 80, on a machine that is multi-homed at IP addresses 1.2.3.4 and 5.6.7.8, then "YES".
If you mean to say: two different images, one listening on 1.2.3.4:80, and the other listening on 5.6.7.8:80, then "NO"
Here is another example:
One image can listen on port 80, and "throws away" requests that weren't directed to IP 1.2.3.4, thus it is "listening" only to 1.2.3.4:80.
Another image running on the same machine listens to port 8080, and "throws away" requests that weren't directed to IP 5.6.7.8, thus it is "listening" only to 5.6.7.8:8080.
The two images can even forward requests back-and-forth to each other (and thus serve as a network bridge between the two IP's).
But they can't both be listening on port 80. That won't work.
Nevin
Judging from the other replies, it looks like there has been some changes/improvements. Good deal.
Nevin
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Chris Burkert -
Craig Latta -
David T. Lewis -
Frank Shearar -
Ian Piumarta -
Jimmie Houchin -
John M McIntosh -
John Pfersich -
Lex Spoon -
Nevin Pratt -
Peter William Lount