Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!well!shf From: shf@well.UUCP (Stuart H. Ferguson) Newsgroups: comp.sys.amiga.tech Subject: IPC - IPCMessage and Networks Message-ID: <5872@well.UUCP> Date: 3 May 88 22:38:57 GMT References: <5699@well.UUCP> <9131@agate.BERKELEY.EDU> <5819@well.UUCP> <9343@agate.BERKELEY.EDU> Reply-To: shf@well.UUCP (Stuart H. Ferguson) Organization: The Blue Planet Lines: 101 Keywords: IPC, standard, network Summary: Possible problem in dealing with networks In looking over Pete's IPC.h and the Pete/Peter IPCMessage design, I have come to find what may be problems with the basic approach. Pete replied quite lucidly to my questioning the use of an array of pointers instead of something more general such as a linked list, and I think I can justify that decision for myself. The objection I have now is somewhat more serious, however. Pete says: > ... One of the design goals > (!) of the IPCMessage was that an "ignorant" server could for instance pass > most items down a network, and would know which ones it couldn't, without > needing any idea of the contents. If a list node can contain "anything" we > come bang up against my main objection to AREXX -- that its pointers can > also contain "anything", so every process has to know "everything". What's > a poor dumb server to do? Pete's "for instance" example of passing messages down a network is really the *only* purpose I can find for defining a standard such as this. I can't see any other reason why a program would examine the contents of a message unless it was the server for the message in which case it would know what to expect a-priori. So first of all, are there any other uses of "dumb" servers besides network front-ends? I think the IPCMessage format is going to run into some problems dealing with networks. Not the least of these problems is how does a network server attach itself transparently into the IPC system? Will client programs have to talk explicitly to a network server, or will they just attach to a server and not care if there's a network involved? If this is to be handled transparently using the functions specified in IPC.h, then networking would have to be *built-in* to these functions. How will network servers be supported? Another problem is much more subtle. It seems to me that the only way to test if a given client-server protocol will work over a network is to actually test it using a specific network server. The reason is that many of the flag bits specified by the Pete/Peter standard have little meaning for clients and servers, but have _crucial_ meaning for a network server. As result, programs which work fine running on a single Amiga could break trying to run on networked Amigas. Worse still, programs that work while running one network server could break when running with a different server. By way of example, consider a client (C) and a server (S) using the proposed IPC mechanism. The relationship between the two consists of "C" sending some data to "S" in a message and "S" modifying it and replying. The data gets communicated using one IPCItem with a pointer to the data block which is not included in the message itself. Now let's say that "S" forgets to set the IPC_MODIFIED flag even though the data for that IPCItem does get modified. This mistake could be deadly to networks in a subtle and nasty way. The communication will work fine on a single Amiga since neither "C" nor "S" really care about the state of the IPC_MODIFIED bit in the returned message. "S" justs modifies the data in place in memory and when "C" gets the message back it has control of the modified data. The communication could break down when using a network server as intermediary, however. The network front-end will transmit the message and the data over the network for the "S" process running on the remote system. The remote "S" will modify the data but will again FORGET to set the IPC_MODIFIED bit for that IPCItem. Now, the network server, crafty and efficient as it is, _does_ examine the IPC_MODIFIED bit and only sends back the data blocks which have been modified, so the modifications that "S" made do *not* get transmitted back over the network. As result, when the message comes back to "C", the IPCItem still points to unmodified data and "C" has failed to get what it requested from "S" at all. But it's worse than this. What if the programmer who wrote "C" and "S" DID test them out over a network, but the network he used was dumber than the network described above? This "dumb" network server might always transmits all the data in the message without regard for the IPC_MODIFIED bit. In this case, the server would transmit the data, the remote "S" program would modify it and the network server would transmit the modified data back again so that "C" sees the modified data. The programmer says, "Great! It works over a network -- call the publisher!" The user with the "smart" network server on the other hand says, "(sarcastically) Great!! So it works over a network, huh? Call the publisher ..." The general problem is that the IPCMessage is a "soft" standard. It's just a set of rules and nothing breaks if programmers violate the rules, except down the line when someone expected the rules to be followed. It's rather like expansion memory in the old days of Amiga programming -- the rule was to put all images into chip ram, but since everything was chip ram a lot of programmers didn't follow the rules. God knows what will break if/when we get an MMU on the Amiga. Shared data is _supposed_ to be in public memory, but since everything is public, how do you test it? The specific example I gave could be tested against by having a NETWORK_TEST mode for message ports so that the message passing functions would simulate a network and catch all the unexpected nasties. Seems like a lot of overhead to have in the functions themselves, however. -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC (shf@Solar.Stanford.EDU)