NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/sys/next/programm/7987

Internet Message Format | 1993-01-05 | 5.5 KB

Path: sparky!uunet!psinntp!sugar!tghost!unkaphaed!biff!biff
From: [e-mail] (Dwight Everhart)
Newsgroups: comp.sys.next.programmer
Subject: Re: Sending objects between processes (SUMMARY)
Summary: Distributed objects are the way to go.
Keywords: distributed objects, typed streams, speaker listener
Message-ID: <[e-mail]>
Date: Tue, 5 Jan 1993 06:29:35 GMT
References: <[e-mail]>
Sender: [e-mail] (Dwight Everhart)
Lines: 98

In article <[e-mail]> I wrote:
> I'm writing a software system involving a server process and several client
> processes.  I'm writing them in Objective-C, although the server is a
> daemon, not an application (it doesn't have a NXApp).  The clients may or
> may not be applications.  I'm using Speaker and Listener objects for the
> RPC requests.
>
> I need to be able to send objects between the clients and the server.
[Description of first approach deleted.]
> My second (and latest) approach is to use typed streams on ports, and send
> the objects using NXWriteObject() and NXReadObject().

I ended up using a typed stream on a memory buffer, and then sending the
buffer to the other process through a block in a Speaker/Listener message.  I
switched to buffers because of an interesting problem I had with ports.  I
was keeping the typed stream open and sending several objects through it.
However, when the stream was read, only the first object was returned, no
matter how many times it was read or how many objects were written to it.
Apparently only one object can be sent over one typed stream.

The solution was to open a typed stream for each object.  Since I wanted to
minimize the amount of code I had to write, I switched to buffers.  NeXT
already provides a function, NXWriteRootObjectToBuffer(), that allocates the
buffer, opens the typed stream on it, writes the object, truncates the
buffer, and closes the stream -- all in one function!  There isn't an
equivalent function for ports.

The system seems to be working now, although I am not sure who should be
freeing the memory buffer sent through the Speaker/Listener message.  The
manual says that NXFreeObjectBuffer() should be called to free the buffer
when it is not needed anymore.  However, the same manual says that blocks
sent in Speaker/Listener messages are automagically freed.  So who frees
memory buffers created by NXWriteRootObjectToBuffer() and sent through a
Speaker/Listener message?

As I said in my previous article, I'm not using distributed objects because
I'm running 2.0.  I'm hesitant about upgrading to 3.0 because of it's
performance impact (I have an '030 cube) and its bugs.


> If you know of a better way to send objects between processes, please
> explain.  I'm running 2.0, so I don't have distributed objects.  Do they
> offer a better approach?

Three people replied, and they all suggested distributed objects.


Montgomery Zukowski <[e-mail]> writes:

>         I think that sending objects over typed streams will work fine as
> long as you also send the class to be dynamically loaded, probably easiest
> to send the filename of the modules to link in, although for security you
> might want to send the object data itself.
>         Even distributed objects in 3.0 requires that the classes of
> objects be loaded in the recieving progrtamm so that copies can be
> instantiated when they are recieved.  Distributed Objects does have a
> transport protocol which specifies how to encode and decode objects which
> are passed between programs, you might want to look at it for ideas.  It is
> needed because some objects passes may be distributed objects while others
> are going to be copied and instantiated.  If you don't need to maintain
> connections accross programs, then you don't really need distributed
> objects.  From your description you seem to only need to pass objects and
> not maintain a connection to the server's objects.


Timothy J. Wood <[e-mail]> writes:

>   Yes!  They handle everything for you (except making sure the class in
> linked in).  For example, say I have two processes, A and B.  A has a list,
> and B has some items that it wishes to put in A's list.  A would simply
> 'vend' the object (two lines of code).  B would look up the vended object
> (one line of code which returns an id).  B could then treat that id exactly
> like it was the real object since all messages to it would be bundled up
> and transmitted to the real object.  When B sends it's object id's to the
> proxy for A's list, it could specify to send a copy, rather than the whole
> object.
>   I would strongly suggest that you take a look at Distributed Objects.
> They are by far the coolest thing that NeXT has done in version 3.0.


Paul Burchard <[e-mail]> writes:

> Distributed Objects is the best way to do all this stuff, even with
> the extra twist of dynamic loading.  You can do what you want, with
> fine control over freeing responsibilities and good transparency to
> the rest of the code, using the NXTransport protocol (one of the
> highlights of D.O.).  Check it out and ask me if you need more
> info...


Thanks to all who responded.  Although distributed objects sound good, I'll
use typed streams for now, since I have them working, and I don't have 3.0.

--
Dwight Everhart          "Spring will come for IBM when people
Houston, Texas            start buying big computers again."
[e-mail]      -- John Akers, CEO of IBM
NeXTMail and MIME OK