Xref: utzoo comp.sys.amiga.tech:169 comp.sys.amiga:17137 Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pasteur!agate!violet.berkeley.edu!pete From: pete@violet.berkeley.edu (Pete Goodeve) Newsgroups: comp.sys.amiga.tech,comp.sys.amiga Subject: Re: IPC: Messages (again) [+ -- Oopsie.] Message-ID: <8250@agate.BERKELEY.EDU> Date: 2 Apr 88 08:51:28 GMT References: <7685@agate.BERKELEY.EDU> <806@nuchat.UUCP> <7929@agate.BERKELEY.EDU> <864@nuchat.UUCP> <1771@sugar.UUCP> Sender: usenet@agate.BERKELEY.EDU Reply-To: pete@violet.berkeley.edu.UUCP (Pete Goodeve) Organization: University of California, Berkeley Lines: 111 Keywords: IPC Message Format Summary: Final touches? Responding to two of Peter da Silva's messages at once... From <864@nuchat.UUCP>: > < [Me:]... > < think that we should add a UnkmownMsg() reply procedure (which would set > < the type to NT_UNKNOWN) as a format-independent way of telling the client > < it's out of luck. [....] > > I don't see why you want to overload data onto this channel. Would another > USHORT in the body of the message be too much to ask for? This was part of my fight to retrofit to other-format messages. I guess I've retired from that particular fray... We'll just reserve a bit or two in the IPC_Status field. > < struct IPCItem { > < ...... > < void *IE_Ptr; /* points to defined data structure (could be within > < message block if IE_Id says so) */ > < }; > > I wouldn't want to put it into the message block depending on ID. Matt > Dillon's point about not having to know the ID to pass a message > along is a valid one. Agreed. My original thoughts were to have the ID control the format, as it does in IFF, but that becomes impractical when you take all the points Matt and other people have raised into account. See below for more... > > OK, let's go with "Item". struct IPCItem and all. (that what you mean?) Yaay!! [jumps up and down in high glee...] Nynhh Hynhh.. I like dis game! > -- From <1771@sugar.UUCP>: > > In my last IPC message I said that only pointers should go in the pointer > field of the IPCItem structure. That was totally bogus... you should be > able to put RastPorts, Locks, anything in there. ^^^^^^ that'll fit into a longword I assume.. > > But you still need to be able to let IPCGateways know about them if they > can do anything with them. > > How about this. If the size feild is zero, then that means "Mind your own > business, Spock, I'm sick of your half-breed interference". So IPCGateway > can copy stuff through with non-zero size feilds, and leave bad ones behind. A good thought, but does it go far enough? The problem seems to me that the server may need -- so far! -- at least three items of information about an item: 1) "You (the server) can take responsibility for this item, and free it when you're done" 2) "The contents of this item may be transmitted elsewhere" (i.e. not a lock etc.) 3) "This item is included in the mn_Length" (maybe this could be flagged by a size field of zero, but there's always the chance we might like the size for some other purpose). These are pretty independent. One item might be a port structure, say, that could be passed to another process but not down a network; or a buffer could be transmittable, but kept by the client. I think IE_Size==0 should be reserved to indicate that the item is NOT a pointer. Looks like we're forced into YAFF (Yet Another Bloody Field) in each item that you can put these flags in -- and all the others we'll think of. I thought at first a single Flags word at the head of the message might be enough, but I suspect we'd surely want items with different characteristics in the same message (command fields that remained client's property, with buffers to be passed on, for example). I suppose we might as well make it a long word, but maybe split off 16 bits for item dependent flags (ignored by processes which didn't understand the ID). We probably also ought to allow the server to set some of the bits to indicate, for instance, "Don't know about this item" (This wouldn't be set by processes such as a network handler -- only by a server that the client sent the wrong type of item to). So, Revision k+1?: struct IPCItem { ULONG IE_Id; /* strictly determines meaning of data referenced */ ULONG IE_Flags; ULONG IE_Size; /* size of data structure -- I think we need this */ void *IE_Ptr; /* points to defined data structure (could be within message block if IE_Flags says so) */ }; /* Flags set by client (tentative, natch...): */ #define IPC_IE_TRANSFER 0x08000000 #define IPC_IE_NETWORK 0x04000000 #define IPC_IE_INMESSAGE 0x02000000 /* Flag returned by server (ditto): */ #define IPC_IE_NOTKNOWN 0x80000000 I actually have NO suggested changes to the previous message structure...! -- Pete -- [ BTW: > -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' ^^^^^ how many of these do you have? There's a Peter daSilva (sic) doing some good photo work for the campus newsrag. (If I had a DigiView, I'd send you a sample...) ]