IPC and SRP...

Rob Withers withers at vnet.net
Sat Aug 26 03:11:10 UTC 2000


"Göran Hultgren" wrote:
> 
> Hi!

> Well, I am trying to design/prototype a rather complex server where I need IPC and multiple VMs
> running (similar to GemStone but simpler) and they need to talk to each other in some sort of nice
> way. :-)

Göran,  I want that too.  I have some AI stuff to do.  We could approach
a GemStone architecture by using headless minimal images and have a
resource manager in yet another image.

> > also been looking into an 'RMI' solution and one of my big concerns is
> > that it be cross-dialect.  There is a xdialect Serialization
> > framework.   SRP runs - I think - on Squeak (2.7+), VW 3.x and 5i, VAST
> 
> Yes, after reading about this (and your comments) I realized that Segments where not "a different
> beast" that I thought them to be (I had gotten the impression that they where "High Performance"
> compared to "normal" SmartRefStream, but that was obviously a misconception from my side).

So, I should have stated that I really had no idea what or how Segments
work.  I briefly looked into the Root computation stuff and didn't have
the full picture.  I learned that they don't use SmartRefStreams and
that there is VM support for them, so they are extremely fast.  It
certainly is a serialization mechanism.  Sorry.

> Soo... Then SRP and SmartRefStream remains in the fray. And SRP sounds more efficient AND portable
> too. Hmmm... ;-)
> 
> > 4.0+?, StX, Dolphin, and ObjectStudio.  Paul has said that we should be
> > able to decode structures from other languages like Java.  There are
> 
> That is pretty cool actually. It would be interesting to hear more from Paul about SRP compared to
> IIOP (CORBA), which I would guess to be the number one competitor in the "open standards" space -
> any thoughts?

IIOP is only the session protocol for Corba; I guess they have separate
serialization standard, don't they?.  We could probably form the rules
of Corba serialization in SRP.

> > some issues with Squeak wrt Processes, BlockContexts, Semaphores, and I
> > believe any Class that doesn't have a rule dumps it's entire Meta
> > hierarchy - this somehow pulls in Smalltalk, though ProtoObject.   What
> 
> Oops. :-) But that sounds fixable.
> 
> > is missing from a xdialect 'RMI' solution is xdialect Sockets and
> > Streams.  Perhaps at CS at OOPSLA this will be a project.
> 
> Eh, lost me there. xdialect?

Sorry, I was trying to abbreviate cross-dialect.

> > I have attached the small extension I made to substitute a handle for a
> > particular class.  When a graph of objects gets encoded and one of the
> > objects is of a class included in the HandleSubstitution rule, the
> > object and it's assigned handle get registered in the HandleManager,
> > then the handle gets encoded.   When you decode a graph of objects from
> > a binary stream and you find a handle, then you register that handle as
> > a proxy.  This is to support GC which I haven't gotten to yet.  I am
> 
> Ehum. Have to study this more closely. It sounds like a mechanism to define the stublevel in the
> serialized object structure. But what has GC got to do with that?

Yes, except you can't specify a depth-based stublevel (edges from the
root before handle substitution occurs), yet.  Hopefully, it computes
the next edges after it has converted to a handle, but we could write a
special subclass of ObjectSaver that did that.

> > currently migrating a small proxy front-end which will DNU the message
> > to the handle and forward the msg to wherever the proxied object is (I
> > hope!) - Remote, Persistent, cross-Language...
> 
> Yes, the "normal" way to construct proxies/stubs in Smalltalk. Nice! Long live transparency.

It would be nice to have VM level support for forwarders as you can't
forward all messages with DNU.  It would also solidify the redirection
semantics so we could put any implementation behind it that we wanted.

> > I also have a client-server framework that I adapted to use SRP streams;
> 
> Yes, I think I found it when I was roaming about, but perhaps you have a link to the current
> stuff?

I'll post this tomorrow, once I have baselined it.
 
> > it *isn't* using Flow, yet.  I would really like to see that.  I have
> 
> Perhaps that could wait until Flow sortof gets consolidated into Squeak - please somebody, people
> are cranking out network apps in Squeak every day now - this should have a high priorioty IMHO
> 
> > some testCases.  These two pieces together, with a pumped endpoint and
> > use of when:send:to: could result in a pretty robust base for IPC
> > between Smalltalks.  It still needs a lot of work in naming/locators,
> > exceptions and remote event registrations.  I can provide this too you
> > if you want it.  I'll need some time to consolidate and test.
> 
> Do I want it? H#ll yes! :-)
> 
> > I hope this helps!
> 
> You bet.
> 
> [snip]
> > > 1. Fly-By-Wire and similar stuff. Anyone using it?
> >
> > Is this the ORB?  I haven't tried it yet; any info would be most
> > welcome.
> 
> It was built by Tim Jones and Peter Smet if I read correctly at:
> http://minnow.cc.gatech.edu/squeak/684
> 
> Unfortunately the linki does not work anymore - does anybody know more about it?
> Is that overlapping your stuff? Perhaps you should look at it... ;-)

This was my experience.
 
> There are some other links on that page too for stuff by Lex Spoon and Stefan Matthias.

I've been all through their code and I wonder if there is advantage to
making a more complicated solution, at times. 
 
> > > 2. Serialization. Anyone using it for communication? Has anybody tried comparing the
> > marshaling
> > > techniques available to Squeak (SmartRefStream, SRP by Paul Baumann, Segments)?
> >
> > I don't know the performance measures of either SRP or SmartRefStream.
> > Segments use SmartRefStreams and are really a file-based module delivery
> > mechanism.

DOH!  My nose grew!

> Ok. My mistake. Will have to read up more.
> 
> > > 3. Flow (former Correspondents). Anyone using it? Is it EVER going to get integrated into
> > Squeak?
> > > I mean... it seems so much nicer. :-)
> >
> > It is a really nice framework, minus some confusion I have about the
> > Stream hierarchy replacements.  It renames the Stream hierarchy,
> > OldStream, and this stepped on some subclasses I had.  I believe this is
> > only because it still hasn't made it into the update stream.  This may
> > be because of the VM changes that recently occurred.  The NetStream is
> > gorgeous.
> 
> You mean on the Socket level? Well, perhaps Craig or SqC has some answers.
>
> I have looked quite a bit at uses of ConnectionQueue, Socket (Nebraska, PWS etc.) in the image and
> it looks like a lot of code is repeating itself over and over... And I believe Flow has some more
> highlevel stuff which would put that stuff in one place.
> 
> Well... So in short, a very nice IPC could be created by melting together:
> 
> 1. Flow
> 2. SRP
> 3. Fly-By-Wire and your similar Proxy stuff (perhaps these two parts should be merged into one -
> no sense in duplicating efforts)

There probably is a lot of sense in duplicating efforts in the
exploratory stages.  The is more fitness space covered, for instance,
the AOP stuff, Capabilities, all of the other networking choices, are
all somewhat related, I think.   Perhaps there is an intersection of
these semantic dimensions.

> And BTW - Unix domain Sockets - do we have any support for those? I have concluded that these are
> FAST compared to "normal" Sockets. On the Linux platform it seems that Linus himself has
> "optimized the crap out of them" as someone so eloquently put it on /.

You can probably get at them with the UnixOSProcess stuff.  

> Ok, enough jibbering.

Me too  :)

cheers,
Rob
 
> regards, Göran
> 
> =====
> Göran Hultgren, goran.hultgren at bluefish.se
> icq#:6136722, GSM: +46 709 472152, http://www.bluefish.se
> "First they ignore you. Then they laugh at you.
> Then they fight you. Then you win." -- Gandhi
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Mail - Free email you can access from anywhere!
> http://mail.yahoo.com/

-- 
--------------------------------------------------
Smalltalking by choice.  Isn't it nice to have one!





More information about the Squeak-dev mailing list