|
Here is PHONE protocol as taken from the V4 VMS source tape. Having
sources online is so much nicer than going ficheing.
Enjoy.
matt
P H O N E P R O T O C O L
--------- ---------------
PHONE uses what are essentially half-duplex links between processes.
A process, known as the Master, sets up a link to a network slave on the
node in which it is interested. Some of the communication occurs between
the Master and the network slave. If the Master wishes to communicate with
a user on that node, known as the Target, then the network slave sets
up communication with that user. The resulting Master-slave-Target
link is a one-way link. If the Target in turn wishes to communicate back
to the Master, it reverses the procedure, resulting in two links for the
conversation.
The protocol has been made as asynchronous as possible. This means that
messages can be sent in essentially undefined order, and received similarly.
The PHONE program must be robust enough to handle all situations. There
is only one case where a certain message must be sent first, as described
below.
All messages sent from Master to slave are of the following format:
+----+--------------+-------+
|msg |sender |message|
|type|identification|text |
+----+--------------+-------+
The message type is a 1-byte code identifying the type of message
being sent. See the descriptions below.
The sender identification is an asciz string identifying the sender
of the message. The identification is in the following format:
node::user
The message text is optional additional information qualifying the
message.
Many of the messages sent from Master to slave are simply to be relayed to
the Target. A few messages, however, are handled directly by the slave,
which may then return information to the Master. Thus the Master-slave
portion of the link is two-way. The following paragraphs describe the
various messages.
CODE DESCRIPTION
---- -----------
7 This message is sent to the slave when the Master wants to verify
the existence of some person. It is the FIRST message sent to the
slave when a link is created for the purpose of talking to
someone. The message text is the identification of the desired
target, in the following format: node::user. The slave must
verify the existence and validity of the Target, and then return
a status as described below.
8 This message is sent when the Master wants to ring the Target's phone.
The message text is a 1-byte flag, true if this is the first ring
for this call, false otherwise. The slave must try to ring the
phone, and then return a status as described below.
9* This message is sent by the Master when it wants to hang up on the
Target. The Target then knows that the Master is breaking the link.
10* This message is sent by a Master when it is busy and cannot perform
an operation requested by some other process. This typically occurs
after a Target has established a link back to a Master, thus becoming
a Master itself. It then would send a busy message if it couldn't
handle a ring, for example.
11* This message is sent by a Master when it answers a call from another
Master. This occurs after a Target has established a link back to
a Master, thus becoming a Master itself. When the original Master
receives this message, it knows that the Target has established
a return link and can answer the call.
12* This message is sent by a Master when the user rejects a call from
another Master. This occurs after a Target has established a link
back to a Master, thus becoming a Master itself. When the original
Master receives this message, it knows that that Target has
established a temporary return link and that the user does not
want to answer the call.
13 This message is sent to the slave when the Master no longer needs it.
It tells the slave to exit.
14* This message is sent by the Master when it has a conversation text
fragment for the Target. The message text is one or more characters
of conversation.
15 This message is sent to the slave when the Master wants the next
directory line for a remote directory. The slave must build the
directory line, adhering to the format as displayed on the screen,
and return it to the Master. If there are no more processes to
display, the the slave should return a null line. NOTE that the
slave exists only for the duration of one remote directory command.
17* This message is sent by the Master when it wants to force the Target
to set up a link to a third person. It is used when the Master
establishes a conference call, in order to force all existing
participants to recognize the new person. The message text is an
identification of the new person, in the following format:
node::user.
18* This message is sent by the Master when it wants to put the Target
on hold.
19* This message is sent by the Master when it wants to take the Target
off hold.
* These messages are simply relayed from the slave on to the Target.
Some of the messages handled directly by the slave require the slave to
return a status to the Master. This status is always a 1-byte code selected
from the following table.
CODE DESCRIPTION
---- -----------
0 Some problem has occurred that is not covered by other codes.
1 The operation was completed successfully.
2 A user identification (node::user) was syntactically invalid.
3 Something prevented the slave from communicating with the user.
4 The user identification (node::user) was missing the user name.
5 The slave does not have the necessary privileges.
6 The specified Target user does not exist.
7 The Target's terminal cannot be used by PHONE.
8 The Target logged off during the procedure.
9 The Target's phone is off the hook (e.g., /NOBROADCAST set).
NOTES
-----
1. The user identification parser must be able to handle
strings which are more complex than the format given above.
The complete format is as follows:
[[_]node::]...[_]node::user
The last node is the home node of the user.
2. The Master must be able to handle random deaths of the slave.
The slave will simply vanish if it gets totally confused.
|