RE: [PROP] Socket Portability Classes (was Re: Taking Swazoo Forward [Long])

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

RE: [PROP] Socket Portability Classes (was Re: Taking Swazoo Forward [Long])

Jerry Bell
Looks good to me.  Also remember that the Resource name wasn't Dolphin-friendly.
 
Are the ObjectMemory references basically used to force socket finalization when you're closing down Swazoo cleanly, so you can restart immediately?  Perhaps they are used to hook image startup/shutdown as well?   I don't remember and my VWNC image is at work. 
 
I think it would indeed be a good idea to isolate those sorts of things into their own object.   We should list the services required from an object such as this and design the protocol from there.  SiteRegistry is already there, but doesn't feel right for these sort of grungy and very implementation specific details.   Unfortunately, I can't think of a good name for the object right now. 
***
Here's a quick design problem that those of you who are more experienced can help me with: Assume we go with AbstractSwazooSocketServer, with subclasses providing implementation-specific behavior.  I don't want to go through the VW source replacing occurrences of VWSwazooSocketServer with DolphinSocketServer.  What is the best way of dealing with this- do you add a new subclass, and also change a method in AbstractSwazooSocketServer which would answer the right kind of SocketServer? 
 
AbstractSwazooSocketServer>>implementationSpecificServer
    ^DolphinSocketServer new
 
Here I don't like the fact that you are referring 'downstream' in AbstractSwazooSocketServer's own inheritance hierarchy.  Doesn't feel quite right.
 
Maybe you build a ServerSocketFactory which does the job?  Or something else?  There's probably a pattern for this out there somewhere.
***
 
Also, I'm hoping to bring the Dolphin port up-to-date this weekend.   Are the VW files on SourceForge the most current?  
 
Thanks,
 
Jerry Bell
 
 
 
 -----Original Message-----
From: Ken Treis [mailto:[hidden email]]
Sent: Saturday, October 21, 2000 5:17 PM
To: [hidden email]
Subject: [PROP] Socket Portability Classes (was Re: [Swazoo-devel] Taking Swazoo Forward [Long])

Jerry Bell wrote:
I agree that keeping the code in sync across platforms may be a problem.
The Dolphin port is quite behind, but my free time situation should be
improving soon.  I'm planning to let the current changes to the VW parcels
settle, and then port those changes to Dolphin.

Still, there will still be some lag in propagating changes across platforms
unless we are able to figure out some way to isolate code that is completely
portable across platforms from code which isn't.  The lag probably won't be
too drastic, so it may not be worth the effort.  Also, it probably makes
sense to wait until a Squeak port has been completed, so that we have 3 data
points as to what bits aren't completely portable.

After reading this (and a couple of your other messages) as well as doing some Squeak playing on my own, I'd like to propose the following changes to the Swazoo socket code.  Hopefully, these should ease portability -- at least as far as the socket layer goes.

Change 1: Pull the socket-serving code out of HTTPServer.  In this scenario, the HTTPServer would instantiate a SwazooSocketServer.  The socket server's job is to create a listening socket, block waiting on it, and evaluate a block -- a handling block, if you will -- with a newly accepted stream as an argument.  Then, the HTTPServer code looks something like this:

initialize
    ...
    server := SwazooSocketServer port: port.
    server handler: [:stream | self interactWithNewConnectionOn: stream]

start
    server startServing

interactWithNewConnectionOn: aStream
    conn := HTTPConnection stream: aStream.
    self addConnection: conn
    conn interact

There are parts of this operation that'll be platform specific -- we have to create a new socket, listen on it (this object will encapsulate the serveLoop that's now in HTTPServer), create a new stream, evaluate the handler, and repeat.  Therefore, I propose that we make an AbstractSwazooSocketServer (the name doesn't have to be that heinous) that has as much common code as is possible.  Then, we implement a SwazooSocketServer subclass in each dialect.  HTTPServer should then be completely portable.

I'm not sure how we'd test this -- ideas?  Perhaps we could create internal streams, call the interactWithNewConnectionOn: method ourselves, and make sure that the server appropriately creates new connection objects, adds them to its collection of them, and starts them up.

Change 2: We do the same kind of thing with our streams.  VisualWorks lets you create a readAppendStream on any socket.. while Dolphin has some sort of socket stream and Squeak's sockets don't behave like streams at all (though it's not hard to make them do that -- I've written one that we could use as a starting point).  SwazooStreams would need to do the standard stream operations (most of which could be written in an abstract class), and we'd also make them able to tell you what the IP address of the remote site is.  Perhaps we could even put utility methods in SwazooStream class for name resolution if we need them.

SwazooStream would wrap whatever dialect-specific stream is needed, and most of the methods in SwazooStream would just forward to it.  That gives us a unified interface to the streams across dialects.  We could also make our own protocol for binary puts (e.g. nextPutBytes:, since most of the time we want to spew raw bytes in large chunks) instead of using the VisualWorks binary/text mode flipping.  Heck, we could even add SwazooStream>>crlf, nextLine, etc, thus eliminating the need for the silly LineStream.

This should be pretty easily testable, too, if we just point the SwazooStream at an internal stream and test the behavior of nextPut:, next:, and the like.

----

All of this is to try to isolate the non-portable parts so that it's easier to keep our different Swazoo ports up to date.  Every Swazoo resource should use the SwazooStream protocol, and then Swazoo apps will at least be portable in that respect.  Other hurdles might include an EndOfStreamNotification (we can probably make SwazooStream handle this), as well as any references to ObjectMemory (doesn't work for Dolphin).

Thoughts, everyone?
 

Ken Treis
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PROP] Socket Portability Classes (was Re: Taking Swazoo Forward [Long])

Joseph Bacanskas
Hi:

At CampSmaltalk @ OOPSLA, Janko and Benny brought the tests forward to
the level of Janko's changes.  As soon as I get the code, I'll
update SF.  Should be soon. ;-)


Jerry Bell wrote:

> Looks good to me.  Also remember that the Resource name wasn't
> Dolphin-friendly.Are the ObjectMemory references basically used to
> force socket finalization when you're closing down Swazoo cleanly, so
> you can restart immediately?  Perhaps they are used to hook image
> startup/shutdown as well?   I don't remember and my VWNC image is at
> work. I think it would indeed be a good idea to isolate those sorts of
> things into their own object.   We should list the services required
> from an object such as this and design the protocol from there.
> SiteRegistry is already there, but doesn't feel right for these sort
> of grungy and very implementation specific details.   Unfortunately, I
> can't think of a good name for the object right now. ***Here's a quick
> design problem that those of you who are more experienced can help me
> with: Assume we go with AbstractSwazooSocketServer, with subclasses
> providing implementation-specific behavior.  I don't want to go
> through the VW source replacing occurrences of VWSwazooSocketServer
> with DolphinSocketServer.  What is the best way of dealing with this-
> do you add a new subclass, and also change a method in
> AbstractSwazooSocketServer which would answer the right kind of
> SocketServer? AbstractSwazooSocketServer>>implementationSpecificServer
> ^DolphinSocketServer newHere I don't like the fact that you are
> referring 'downstream' in AbstractSwazooSocketServer's own inheritance
> hierarchy.  Doesn't feel quite right.Maybe you build a
> ServerSocketFactory which does the job?  Or something else?  There's
> probably a pattern for this out there somewhere.***Also, I'm hoping to
> bring the Dolphin port up-to-date this weekend.   Are the VW files on
> SourceForge the most current? Thanks,Jerry
> [hidden email]-----Original Message-----
> From: Ken Treis [mailto:[hidden email]]
> Sent: Saturday, October 21, 2000 5:17 PM
> To: [hidden email]
> Subject: [PROP] Socket Portability Classes (was Re: [Swazoo-devel]
> Taking Swazoo Forward [Long])
>
>
>      Jerry Bell wrote:
>
>     > I agree that keeping the code in sync across platforms may
>     > be a problem.
>     > The Dolphin port is quite behind, but my free time
>     > situation should be
>     > improving soon.  I'm planning to let the current changes
>     > to the VW parcels
>     > settle, and then port those changes to Dolphin.
>     >
>     > Still, there will still be some lag in propagating changes
>     > across platforms
>     > unless we are able to figure out some way to isolate code
>     > that is completely
>     > portable across platforms from code which isn't.  The lag
>     > probably won't be
>     > too drastic, so it may not be worth the effort.  Also, it
>     > probably makes
>     > sense to wait until a Squeak port has been completed, so
>     > that we have 3 data
>     > points as to what bits aren't completely portable.
>
>      After reading this (and a couple of your other messages) as
>      well as doing some Squeak playing on my own, I'd like to
>      propose the following changes to the Swazoo socket code.
>      Hopefully, these should ease portability -- at least as far
>      as the socket layer goes.
>
>      Change 1: Pull the socket-serving code out of HTTPServer.
>      In this scenario, the HTTPServer would instantiate a
>      SwazooSocketServer.  The socket server's job is to create a
>      listening socket, block waiting on it, and evaluate a block
>      -- a handling block, if you will -- with a newly accepted
>      stream as an argument.  Then, the HTTPServer code looks
>      something like this:
>
>      initialize
>          ...
>          server := SwazooSocketServer port: port.
>          server handler: [:stream | self
>      interactWithNewConnectionOn: stream]
>
>      start
>          server startServing
>
>      interactWithNewConnectionOn: aStream
>          conn := HTTPConnection stream: aStream.
>          self addConnection: conn
>          conn interact
>
>      There are parts of this operation that'll be platform
>      specific -- we have to create a new socket, listen on it
>      (this object will encapsulate the serveLoop that's now in
>      HTTPServer), create a new stream, evaluate the handler, and
>      repeat.  Therefore, I propose that we make an
>      AbstractSwazooSocketServer (the name doesn't have to be that
>      heinous) that has as much common code as is possible.  Then,
>      we implement a SwazooSocketServer subclass in each dialect.
>      HTTPServer should then be completely portable.
>
>      I'm not sure how we'd test this -- ideas?  Perhaps we could
>      create internal streams, call the
>      interactWithNewConnectionOn: method ourselves, and make sure
>      that the server appropriately creates new connection
>      objects, adds them to its collection of them, and starts
>      them up.
>
>      Change 2: We do the same kind of thing with our streams.
>      VisualWorks lets you create a readAppendStream on any
>      socket.. while Dolphin has some sort of socket stream and
>      Squeak's sockets don't behave like streams at all (though
>      it's not hard to make them do that -- I've written one that
>      we could use as a starting point).  SwazooStreams would need
>      to do the standard stream operations (most of which could be
>      written in an abstract class), and we'd also make them able
>      to tell you what the IP address of the remote site is.
>      Perhaps we could even put utility methods in SwazooStream
>      class for name resolution if we need them.
>
>      SwazooStream would wrap whatever dialect-specific stream is
>      needed, and most of the methods in SwazooStream would just
>      forward to it.  That gives us a unified interface to the
>      streams across dialects.  We could also make our own
>      protocol for binary puts (e.g. nextPutBytes:, since most of
>      the time we want to spew raw bytes in large chunks) instead
>      of using the VisualWorks binary/text mode flipping.  Heck,
>      we could even add SwazooStream>>crlf, nextLine, etc, thus
>      eliminating the need for the silly LineStream.
>
>      This should be pretty easily testable, too, if we just point
>      the SwazooStream at an internal stream and test the behavior
>      of nextPut:, next:, and the like.
>
>      ----
>
>      All of this is to try to isolate the non-portable parts so
>      that it's easier to keep our different Swazoo ports up to
>      date.  Every Swazoo resource should use the SwazooStream
>      protocol, and then Swazoo apps will at least be portable in
>      that respect.  Other hurdles might include an
>      EndOfStreamNotification (we can probably make SwazooStream
>      handle this), as well as any references to ObjectMemory
>      (doesn't work for Dolphin).
>
>      Thoughts, everyone?
>
>
>      Ken Treis
>      [hidden email]
>
--
Thanks!!

Joseph Bacanskas [|]

--- I use Smalltalk.  My amp goes to eleven.




Reply | Threaded
Open this post in threaded view
|

Re: [PROP] Socket Portability Classes (was Re: Taking Swazoo Forward [Long])

Ken Treis-4
In reply to this post by Jerry Bell
Jerry Bell wrote:
Looks good to me.  Also remember that the Resource name wasn't Dolphin-friendly.
I'm fine with SwazooResource if everybody else is.  :)
Are  the ObjectMemory references basically used to force socket finalization when  you're closing down Swazoo cleanly, so you can restart immediately?   Perhaps they are used to hook image startup/shutdown as well?   I  don't remember and my VWNC image is at work.
I haven't looked in a while, but I believe it was to make sure that sockets weren't persisted when a development image was saved.  When the image was saved, all servers were stopped; after the save, they were started up again.

How important is this to people?  I haven't used the feature yet ... or maybe I have, and I just haven't noticed it quietly save me from disaster?
I  think it would indeed be a good idea to isolate those sorts of things into  their own object.   We should list the services required from an  object such as this and design the protocol from there.  SiteRegistry is  already there, but doesn't feel right for these sort of grungy and very  implementation specific details.   Unfortunately, I can't think  of a good name for the object right now. 
***
Here's a quick design problem that those of you who are more experienced can help me with: Assume we go with AbstractSwazooSocketServer, with subclasses providing implementation-specific behavior.  I don't want to go through the VW source replacing occurrences of VWSwazooSocketServer with DolphinSocketServer.  What is the best way of dealing with this- do you add a new subclass, and also change a method in AbstractSwazooSocketServer which would answer the right kind of SocketServer? 
 
AbstractSwazooSocketServer>>implementationSpecificServer
    ^DolphinSocketServer new
 
Here I don't like the fact that you are referring 'downstream' in AbstractSwazooSocketServer's own inheritance hierarchy.  Doesn't feel quite right.
 
Maybe you build a ServerSocketFactory which does the job?  Or something else?  There's probably a pattern for this out there somewhere.
I wasn't thinking of anything nearly this complicated.  Rather, each language would implement "SwazooSocketServer".  That way, the core code doesn't have to be modified, and we don't have to do any tricks to figure out which server to use.  Just use SwazooSocketServer -- which will be implemented one way for Dolphin, another way for Squeak, and another way for VW.
***
 
Also,  I'm hoping to bring the Dolphin port up-to-date this weekend.   Are  the VW files on SourceForge the most current?
A related question -- should we put the platform-specific file-outs in separate CVS sub-modules?  Joe (Mr. CVS)?  :)

Ken