Path: utzoo!mnetor!uunet!husc6!mailrus!ames!pasteur!ucbvax!agate!violet.berkeley.edu!pete From: pete@violet.berkeley.edu (Pete Goodeve) Newsgroups: comp.sys.amiga Subject: Re: IPC (1): Ports & Messages Message-ID: <7645@agate.BERKELEY.EDU> Date: 14 Mar 88 10:48:18 GMT References: <7412@agate.BERKELEY.EDU> <753@nuchat.UUCP> <754@nuchat.UUCP> Sender: usenet@agate.BERKELEY.EDU Reply-To: pete@violet.berkeley.edu.UUCP (Pete Goodeve) Organization: University of California, Berkeley Lines: 95 Keywords: InterProgram Communication, tools peter@nuchat.UUCP (Peter da Silva) writes: > I don't like the idea of using the replyport for anything but reply messages. > I think there's enough semantic confusion already in the system to add more. In some ways I agree, but on the other hand extra ports also add to the confusion a bit. In any general scheme, a program is going to have to expect messages from various sources anyway, so if replies and original messages are mixed up does it really confuse things much? After all there is that NT_REPLYMSG code I want to be enforced. In the case of a program requesting a "topic" from a message broker, for instance, if the reply port was only used for that -- and you had to specify another destination port -- it would sit totally idle after the initial opening of the channel. I don't think the problem is a critical one; let's leave both options open. > [suggests some possible message IDs, including:] > > 'FILE' followed by a directory lock and a character pointer. > 'CSTR' followed by a pointer to a C string. > 'BSTR' followed by a pointer to a BCPL string. > 'PORT' followed by a message port. > 'FORM' followed by *a pointer to* an IFF FORM. > Making it a pointer shouldn't cause anyone any problems, > and should make it easier to pack stuff into a message. > 'CAT ' > 'LIST' followed by a pointer to IFF CAT or LIST > [....] Great! That's the sort of starter list I was hoping for. A few minor cavils (naturally :-)). You probably shouldn't even mention BSTRs in polite messages... Let's hope that text at least can be standardized to null terminated format (with newlines allowed of course). I agree that IFFs (and other large data items) should normally be referenced by pointers, rather than being in-line in the message, though there are exceptions to this rule (which I want to get into in detail in another posting). I would prefer, though, that we just have ONE message ID for all IFFs (presumably just "IFF ") with the following pointer addressing the actual "FORM" or whatever in its usual place at the head of the data block. We can reserve IDs "FORM", "CAT" and "LIST" for the (rare) occasions they would have to be in-line. > > I like the simplicity and security you get if you always reply to a message > on its reply port. The only thing changed in the reply should be the status > word. Yeh, there should be a status word in the structure somewhere, perhaps > immediately before or after the ID. This ain't always what we want... After all one of the uses of a message is to get a Reply! The normal place to put the information being returned is into the message data block itself, so we cannot insist that the message remains unchanged. Actually the "status" return is another point that needs more discussion. There are two sorts of status as I see it: there's information about whether the server could handle the message or not (essentially YES/NO), and then there's all the other flags that might be connected to a particular message type. The second class should obviously be in the data portion of the message, but the natural place for the first is in the mn_Node.ln_Type slot that is already used for NT_MESSAGE and NT_REPLYMSG. We might even use the null type NT_UNKNOWN for a failed message, but there are lots of spare codes. The only other general status that I can think we might need at the moment is "Server no longer exists", if we implement some Port Broker process. Does anyone see any others? In aother article, Peter writes: > In article ... pete@violet.berkeley.edu ( Pete Goodeve ) writes: > > [about a real neat idea for a message broker] Uh, thanks! > .......... You volunteering to implement it? (half-smiley: > someone has to). I guess I sort of am (whenever I get time!!). I certainly would like to... > For some purposes you still need a port server. It's a lot less overhead once > the connection is made, and it can do some of the same things. It could even > look the same to the user. I've come around fairly solidly to the same point of view. It seems about the cleanest way to solve the FindPort hazard, and it should integrate nicely with the message broker (you either request a port or request a topic). I'm trying to put together a new summary of these points we've been tossing back and forth and get into other things we've left out so far, but that may take a few days.... -- Pete --