Path: utzoo!utgpu!water!watmath!clyde!burl!codas!uflorida!gatech!udel!rminnich
From: rminnich@udel.EDU (Ron Minnich)
Newsgroups: comp.sys.amiga.tech
Subject: Re: IPC (1): Ports & Messages
Keywords: InterProgram Communication, tools
Message-ID: <1401@louie.udel.EDU>
Date: 7 Mar 88 14:23:20 GMT
References: <7409@agate.BERKELEY.EDU>
Reply-To: rminnich@udel.EDU (Ron Minnich)
Organization: University of Delaware
Lines: 25

In article <7409@agate.BERKELEY.EDU> pete@violet.berkeley.edu () writes:
>The rest of the structure should be filled in properly, too, and we should
>be sure that the standard rules are followed.  (I presume -- but haven't
>checked -- that PutMsg sets the ln_Type to NT_MESSAGE, and ReplyMsg sets it
>to NT_REPLYMSG.  Anyone know for sure?)  The receiving program should be
    I know for sure that it does not. I found that out the hard with 
internet.device, where i had to jam NT_MESSAGE into messages IN THE 
DRIVER, even though the messages had been PutMsg'ed. 
>Yeah.. well that's quite enough for now.  Nothing very exotic, but maybe
>it'll be a start on a foundation we can build a flexible IPC protocol from.
>I'll churn out my rationale for a message broker as soon as I can.
>Meanwhile, I'll sit back and wait for the flak on this lot.
   Two thoughts:
1) Seems like we also need a 'port broker'. Isn't that function served
   by PIPE:, or am i missing something fundamental? I.e. rather than
   use ports, just use PIPE: which strikes me as being more reliable?
   Or do we lose something valuable by not using ports?
2) As for the message broker, make it a library, then we in effect
   have multiple copies running for each client ( i am thinking
   as opposed to having a 'port manager' task which will be 
   a bottleneck)


-- 
ron (rminnich@udel.edu)