ENGLE@A.ISI.EDU (11/10/89)
J.Wexler asked some questions about ports in Helios... > I'm almost embarrassed to ask this question,...but I've spent some time > trying to answer it ... Don't be fooled if my reply sounds like I always knew the answer, I've spent many hours on this one too. What is confusing is that Helios is fully distributed and there is thus no single entity who knows about the locations of various processes and ports in the system. This is actually very good since it makes the system topology independent and somewhat fault tolerant in that duplicate servers can be used to account for nodes locking up. > A port is presumably used by at least two parties, one sending a message > and the other receiving the message. A port behaves very much like a socket in Unix. It is a structure local to a processor. The sender dispatches messages to the port of the reciever and the reciever dispatches messages to the port of the sender. Note that these messages are asynchronus and that it is sort of wasteful to sit around waiting for messages to arrive. A very common way of handling things is to always fork a process to manage the port. In Helios, fork creates a thread which executes in the same memory space as the "parent" task, which allows the two processes to interact via shared variables and semaphores. Given that transputer processes are very cheap, this works out very efficiently. > One of them will have to create the port using NewPort. It is not strictly necessary to call NewPort. In simple interactions one can use the task's Port. You can find this port by looking in the include file task.h. It's the field called "Port" in the task structure. Generally there is a one to one correspondence between channels of communication and ports so it is really only necessary to call NewPort if you intend to communicate with two or more processes at the same time. > How does the other party find out the identification > of the port? - in particular, if the two parties are on different > processors? One establishes the initial communication with the port by performing a locate on the desired server. A good example of this is in section 7.6, part II of the manual, its on my page 233, but yours may differ. Look at the way they connect to the mouse server. The server must respond to the locate message and place its reply port in the reply port of the message (which is what you've been waiting for me to tell you). The sender then gets the reply port from the reply to the initial message. The locate function actually performs a distributed search for the server which results in the creation of a path to that server (its pretty neat if you consider that there are not many ways to do the routing if your system is distributed, also this gives you the best path under the current loading conditions). The default action is then to reclaim these ports with the reply message, since most interactions are single transactions. If you are planning on doing more than one transaction, your must set the MsgHdr_Flags_preserve flag in the mcb. Note that the reciever of the initial message must have been waiting for the message on its port -- the aforementioned port in the task structure. This is generally a thread sitting on the port. The official way of implementing this sort of thing is to make the reciever a full fledged server using the various support facilities made for servers. There is a tech note on how to write servers which is available from Perihelion. Servers are a lot like X-windows applications in that once you've written you're first one, you can just keep reusing it and you can forget about most of what is being done. Regards, Steven W. Engle Senior AI Software Engineer MIMD Systems, Inc.