Saturday 8 September 2007

channel or port: a problem of English

I have not posted for some time: during that time I thought a bit about difference between port and channel starting from a chat with Matthew which let me recall what Gary cautioned me initially. For a channel one can read as follows from wikipedia:
Channel in communications refers to the medium used to convey information from a sender (or transmitter) to a receiver.

http://en.wikipedia.org/wiki/Channel_%28communications%29
Well this is what Gary and Matthew told me: a channel is a path between two endpoints rather than a place at which we send some datum. The latter is called port:
A port is an interface between the computer and other computers or devices. Physically, a port is a specialized outlet on a piece of equipment to which a plug or cable connects .... (etc.)
http://en.wikipedia.org/wiki/Computer_port_%28hardware%29
So a channel is a path whereas a port is an interface; and our declaration syntax:
channel chWorld @ World;
looks somewhat strange since a channel cannot be located at an endpoint World: and I can now see why Gary suggested I should use the term "to" as in:
channel chWorld to World;
but at that point I did not precisely see what he was getting at. And then Matthew said a channel is like English channel and it is not a place which you throw a message at and well it is quite right. And I realised a channel in the pi-calculus is a name for a channel and as such it is also a port since it is also an interface: it is a name. A name can be given to a path/medium (even perhaps a path which can be shared by many inputs and many outputs) or to a port and in such a basic formalism as pi all these different notions come out by different usage of names (just as objects and functions and streams and all that can be represented by specific ways of name passing in this calculus).

Perhaps more understandably, one may also say a name in the pi-calculus is a name of a channel: and if we regard that channel's input capability is fixed to some process then it becomes a port of that process.

All in all the main point is we can use "to" if what we are declarting is indeed a channel, as we did above. Alternatively if it is to be a port which we wish to declare --- as the prefix "at" suggests --- then we may as well write:
port pWorld @ World;
Then we can write:
pWorld.greetings(string) from You to World;
which may not be so bad after all.

But if we have two participants which share a port to receive how does it look like?
port pWorld @ {World1, World2};
So pWorld is a port --- an entry point --- in which a message may arrive, to be received by either World1 or World2.Well this sounds slightly magical --- how can a port be placed in two disparate locations? --- and in fact it now sounds more like a channel.....

So may we come back to channel?
channel chWorld to {World1, World2};
Well this makes a better sense: chWorld is the name of a medium, a path, through which a message will be passed to one of these participants. We did extend the idea of "one sender one receiver" idea above, but a communication medium in computing can be more versatile than geographical ones and indeed this generality is a matter-of-fact in the pi-calculus (note however a receiver is almost always unique: we consider a single receiver a default and perhaps even prohibit multiple receivers in some class of applications).

And if "from" is not specified then it means (in principle) anybody can use that channel for sending his or her message as far as a protocol as a whole is well-formed. Here "well-formed" means we do not have a message mix-up as we have seen in Example (1) Asynchrony a fortnight ago (which is here) (by the way having multiple senders may not be so bad in comparison, this time the medium is something like having multiple inlets and a single outlet: we can visualise it as a filter: and of course we can also have a multicast channel too in which a message is always copied to each outlet).

OK so perhaps a channel is still a good idea and we are going to use "to" instead of "at" or "@" when we declare the receiver(s) of a channel: that looks to me more and more natural. But if you have any observations please let us know!