Steve Cavrak <SJC@UVMVM.bitnet> (02/28/90)
Without trying to fuel the "My network is better than your network"
debate too much, I'd like to list the reasons BITNET folks use inter-
active messages. (And I'll list the TCP/IP way of doing the similar.)
The point of the exercise is to present this feature from the users
point of view. Why would anyone in her right mind want to send an
interactive message?
a. to send a command to listserv machine (or other server).
This lets me subscribe to mailing lists, to sign off, to
request files, etc. Yes, I could also do this with a message
in mail (if I can remember whether it is the subjec of the mail
message, the first line of the mail message, the first line after
a blank line, or the first line after a blank line after a line
sacrificed to the infamous line eater of Bargelfloof.
b. to query a remote database.
Such as isaac or any of the list servers that maintain archives
of the lists they service (a very nice feature!). Yes, I could
do this with a remote login if I had interactive login capability
and if the remote host didn't limit the number of logins it would
allow. (And I would very much like to do a catalog search on some
remote libraries!)
c. query whether a host is up.
Yes, ping would work if my system manager would let me use it, but
the interactive "who" tells me where the link fails. (Oh no! Yale
is down again! Drat! ((Honest, no offense intended. I just went
to the wrong football games!)))
d. do a remote name lookup to get the mailing address of William Faulkner.
Yes, I could use the finger program.
.
f. find out who is logged in.
Yes, I could also use the finger program here.
g. Send messages to another user (and brush up on my Spanish in the
process.)
Yes, I could use phone or chat if my system administrator has the
time and courage to port it to my workstation for me.
h. There are probably more. But these are the uses I make and teach in
my bitnet short course.
What makes these particularly useful is that one command does it all.
I can use TELL on the IBM, SEND on the VAX, and something equivalent
on REP (isn't that what the Unix BITNET interface is called? Does it
support interactive messages?)
The TELL/SEND becomes a useful tool (though JNET confuses the issue!)
that can be used over and over.
True, the content of the message changes, but the mechanism is the same.
Steve
Stay tuned for the next installment "What is SENDFILE used for ..."John C Klensin <KLENSIN@INFOODS.MIT.EDU> (02/28/90)
Steve, There is a philosophical issue here and let me preface my response with two observations/qualifications: (1) This is not part of a "My network is better than your network" discussion, it is an attempt to explain the (or "an") Internet point of view. If we can understand better why things are thought about differently in the two contexts, and what concerns enter into that thinking, maybe we can get on with designing solutions that make the best of both worlds. (2) To some extent, the ready existence of some facilities and not others on the Internet *caused* the design decisions about how to do certain things, rather than the need to do those things "causing" the low-level facilities. The same situation exists for BITNET. NJE/RSCS does not support TCP/IP's "one host, multiple sockets, multiple middle- and high- level protocols" model conveniently, nor does it support virtual circuits conveniently, and that caused people, looking for ways to do things to seize on interactive messages and, for example, sender-initiated/password- free file transfer as much as the need for those things caused the facilities to be invented. Similar comments apply about the Internet: both networks were, to some extent, designed with low-level facilities first, then applications layered on top of whatever low-level facilities were in place, not by looking at the applications requirements and desiderata, then designing the low-level facilities. I'm not sure whether this is good or bad; it is a historical reality. In that context, a few comments on your "exercise". -> What you consider a virtue--many services, one facility--is historically considered a vice in TCP/IP-land. There the tendency has been to assume that the right model is "one service, one protocol, one well-known-service and socket set". There are nearly-technical arguments for this in terms of neater layering (most of those applications-level protocols use Telnet, including FTP's command connections, virtually all use either TCP or UDP), but most of the argument for this strategy rather than the one you prefer is aesthetic and/or religious. -> One of the possibilities the Internet model opens up is a lot of administrative flexibility that is much more difficult on BITNET. If, for example, I have a host on which I can permit only trusted programs at the next layer up to use TCP or UDP directly, and can restrict the use of those programs or some of their options, to (or from) particular classes of users, then I can fine-tune network access and facilities. I don't have the problem of wondering whether I want to make "SMSG RSCS..." (or even TELL) restricted access, knowing that, if I don't, I open up the possibility of certain classes of abuses, and, if I do, I cut off lots of reasonable network facilities. Again, I'm not making a claim about relative importance or merit here, only trying to identify a way of thinking about the issues. >a. to send a command to listserv machine (or other server). In this "one service, one protocol..." model, it is hard to make general "Internet" or "TCP/IP" statements here, but two observations are perhaps relevant: (i) Many of the Internet servers operate in exactly this way and send interactive messages. Some -- notably the domain name resolvers themselves -- typically send out UDP datagrams (as close to BITNET interactive messages as you can get, including the 'if it does not get through, it disappears' property) and then wait around to see if anything comes back. Others, like finger and whois and hostname, open a telnet connection to a special socket, send a short message (typically one line), and then the server responds with a burst of information and closes the connection. Two -way interactive messages by any reasonable definition, but hidden by the protocol. And, again, if the server isn't answering, you don't get anything but have to try again later. Fair analogy, what? (ii) To my knowledge, no one has ever attempted to do what LISTSERV does on the Internet, so there isn't going to be a direct analogy. There is no real reason why such a thing could not be done, just as there is no real reason why FTP servers could not be modified on most hosts to accept sender-initiated, password-free file transfers. But LISTSERV is a large and brilliant job, carefully adapted to the character and realities of the BITNET environment. A similar facility that was as carefully tailored to the Internet environment would probably look very different internally, and might rely on different types of facilities. From an Internet perspective, it would probably be argued that having a "LISTSERV-request-protocol" separate from the "LISTSERV-please-distribute-protocol" would permit better error messages, better administrative controls at the source (see above), and *lots* fewer "sub mumble joe smith" messages broadcast to general- purpose lists. >b. to query a remote database. Part of this is a LISTSERV-like issue, the rest of it is a finger/whois/ etc-like issue. It isn't separate. See above. >c. query whether a host is up. Your explanation really raises two issues, one of which has to do with the remote host, and the other has to do with an intermediate host in the chain. From an Internet perspective, they get answered separately. (i) As you note, you ping the thing or, more specifically, bounce an ICMP ECHO packet off it. This is an "interactive message". It is a little more resource-conservative than sending an "interactive command", because no remote database lookup is required (however trivial), unlike a 'who' and only one packet comes back. So the interesting Internet-point-of-view question is "why won't your system manager let you use it?". The answer is that, unlike BITNET, you probably can't get to the low-level facilities--there are good reasons for not having users bouncing ICMP packets around. And most "ping" commands are not designed for "is the remote host up" testing, they are designed for network metering. Consequently, they send lots of packets and meter what comes back and when. What you would want, in Internet-philosophy, is an unrestricted "is that responding" command which would send out one echo packet, of minimal size, wait 10 or 20 seconds for it to come back, and then possibly repeat the process a few times if it didn't, just to be sure that you weren't dealing with a high packet loss or corruption rate. It would be trivial to write, and would not constitute a large resource load on anything. See your system manager and convince him or her that you really need to know this type of stuff. (ii) The second issue has to do with the identification of the bottleneck if you can't get through. Because of the multiple-path, virtual-circuit, adaptive routing character of the Internet, this question is either irrelevant (if you get "equipment busy" on a telephone call to Europe, how often do you find out where the equipment is tied up? How often do you care? and Why do you think the carrier is going to tell you?) or very complex. The "very complex" version involves involves enough gateway- pinging and route measuring to constitute a noticable network load, so it is not a good facility for the casual user. More important, it is very hard to interpret the results in a useful way. When I discover "Yale is down", the next thing I do is to ask Brown how big the queue is for Yale so as to estimate how long it has been down and how long it is going to take my message to get through (you didn't mention that one!). But on the Internet, the queues are on originating hosts, not on intermediate store-and-forward machines and information about what is in those queues is typically considered quite privileged (notice "is", not "should be", about which I have no comment here). And, more important, "Yale is down" typically means a time of some minutes or longer, even given that the operators are on their toes. Because most of the gateways and routers, etc., on the Internet are dedicated (and very simple) machines, not hosts, they tend to be able to reset or reboot themselves very quickly and without human intervention. And, given adequate connectivity, the system just quietly notices and goes around dead links, often in the middle of a mail message or session. So there is a nasty uncertainty-principle variation here: you can find out the status of the network when you asked, not when you encountered the problem or when you are going to use the information. Because BITNET responds a bit more slowly, routing and blockage information is a bit more useful to the casual user. >d. do a remote name lookup to get the mailing address of William Faulkner. >f. find out who is logged in. > Yes, I could also use the finger program here. At the risk of repeating myself, the important thing about the finger program is that it *does* send pretty good approximations to interactive messages. >g. Send messages to another user (and brush up on my Spanish in the > process.) This is a policy matter, not a technical one. There are "talk" protocols on the Internet which, because they are dedicated protocols, arguably work better than flinging low-level interactive messages back and forth. And there has been provision for "immediate delivery to terminal" in SMTP almost since the dawn of that protocol. It is not often implemented, presumably because not enough people have, in practice, needed it. >What makes these particularly useful is that one command does it all. Or particularly harmful and error-prone. See above. >True, the content of the message changes, but the mechanism is the same. But, for any given network, this is ultimately always true: there are always physical and link levels, and all messages pretty much look the same at that level. The critical question is how close to those levels, or even to network level, the casual user should be operating. If the answer is "very far", then you move toward "one service, one protocol, one user-level command". If the answer is "no reason why it shouldn't be close", then you see how much you can do with, e.g., TELL. For historical reasons (and possibly for rational ones), BITNET and the Internet have come up with different answers. --john Klensin@INFOODS.MIT.EDU -------