info-vax (07/16/82)
>From MADLER@MIT-ML Thu Jul 15 18:48:18 1982
We are attempting to design a system somewhat like the Link facility on
MIT-ITS that would allow two or more users to essentially link the
I/O for their terminals together to allow easy communcation. We have
considered a number of methods and wondered whether anyone has other
ideas or suggestions. (By the way, this is on VMS). Potential solutions
include:
1. The user that initiates communication becomes the controlling job
for all processes in the link. His job will connect mailboxes to the other
processes and make sure that I/O reaches every terminal. This method
would not allow the controlling user to leave the link without some messy
work!
2. The user that initiates will open a mailbox to some hibernating process
or will cause some process to come alive that will serve as a channel until
nobody uses it anymore. This seems like a win, although we would rather
avoid spawning a number of jobs of this nature.
We are most interested in efficiency.
Thanks for suggestions!
-Michael Adler
P.S. Please reply to me. I am not on the list.info-vax (07/16/82)
>From FONER@MIT-AI Thu Jul 15 21:17:21 1982
Since you specify that multiple (more than two) users may be present
in the link, having the originating user create a mailbox for
communication is pretty clearly not the way to go, as everybody
suffers when s/he leaves (and there are sufficient conditions for
races unless some algorithm is employed to prevent them when each of
the remaining users tries to initiate communication using a mailbox
each one starts).
Using a global mailbox for communication has some advantages. Each
user could specify the name of the same mailbox, thus identifying
which of possibly several multi-user links s/he wants to participate
in. Note that this avoids a pathological case in which a user manages
to link two or more formerly separate multiuser links (though this
could occasionally be what is desired, I doubt it).
Such a program could be installed with sufficient privilege to create
global mailboxes. The method generalizes nicely to the case where you
have links across networks, using DECnet, in that the program may be
given NETMBX.
Alternately, your idea of a hibernating process sounds interesting.
Given that there must be some way of differentiating two separate
simultaneous conversations anyway, one such process could handle every
link in operation, meaning that you have as overhead only one process
no matter how many users are talking and no matter how many separate
conversation are going on. Again, extending this to DECnet is easy.
If you plan on having the conversation look something like ITS UNTALK
(in which each user gets a portion of the screen so that each may type
simultaneously with no mixups), you'll have to be terminal-independent
unless your installation uses all the same type of terminal. You
could use a TERMCAP-type of system, if one already exists for VMS (I
don't know), or build something under Gosling's EMACS for VMS, if
possible, using EMACS to handle terminal-independence (by simply
having the communications process update the buffer and then asking
EMACS to update its representation of the buffer---such subroutines
are probably accessible, but I've never done that sort of thing under
EMACS, and the last one I've touched is now a year old at least).
Let me know what you come up with. I'm sure that many others besides
me would be interested in such a program... I don't think such a
program exists for VMS, since CHAT allows only two users (using the
mailbox idea where the originator creates the mailbox and the "slave"
dies when the mailbox does).
Ciao.
<LNF>info-vax (07/16/82)
>From LCAMPBELL@DEC-MARLBORO Fri Jul 16 08:20:23 1982
Pardon my ignorance, but wouldn't the easiest thing be to copy
the TOPS-20 LINK feature? You just add a couple of words to
the terminal line database, that can be diddled by an appropriate
system call, so that User1 LINKing to User2 causes User2's
terminal data block to indicate that the terminal driver should
copy all output for User2's terminal to User1's terminal as well.
This certainly sounds easier than spawning processes and mailboxes
and all...
--------info-vax (07/16/82)
>From TIHOR@NYU Fri Jul 16 10:05:08 1982
Did I misunderstand the question? As I interpreted it the feature desired
is a multiuser communication facility the will work under VMS and over
DECnet if desired. Since I have not used the ITS Link facility I am
unsure of what features it offers that DEC's standard PHONE utility doesn't.
The only feature that I can recall hearing of the PHONE claims not
to offer is the ability to record a communication dirrectly from the PHONE
program. (Well, the execute a command interface is a little awkward
since it must use ^Y; SPAWN; and ATTACH. This also means that a user
can not execute a command on someone elses terminal ala TOPS-20 which is too
bad but not a critical flaw since unrestricted access to the facility would
be a major security risk.)info-vax (07/16/82)
>From LECIN@GREEN Fri Jul 16 16:51:46 1982
Au Contrair! My system administrator tells me, that amongst the
other goodies we have on our "newly-received" VMS 3.0, is a program
called PHONE which is the next step along from CHAT. Multi-User!
<M>