Path: utzoo!utgpu!BITNIC!FUTURE-L Date: Tue, 27 Feb 90 10:06:56 EST Reply-To: BITNET Futures List Sender: BITNET Futures List From: "Alain FONTAINE (Postmaster - NAD)" Subject: Re: The fall of Bitnet To: UofToronto LAN redistribution References: Message of Tue, 27 Feb 90 13:40:51 O from Message-ID: <90Feb27.140136est.57720@ugw.utcs.utoronto.ca> Newsgroups: list.future-l Distribution: ut Approved: devnull@gpu.utcs.toronto.edu WARNING : this message should probably be classified as 'philosophy' (and even rotten philosophy, if you want). Skipping it will not alter your understanding of the facts. Reading it, while less dangerous than smoking, may still be a threat to your health. While NJE-IP is certainly an easy (well, for those willing to use it, I don't want to imply that it was easy to develop) way to offer the traditional NJE services (for those who were out of town for the last three years, sender-initiated password-free file transfer and interactive messages) on top of an IP infrastructure, I do have some questions. I do think that those 'traditional NJE' services should be available in any network worth considering as ones only external connection, but I don't feel NJE-IP as a correct way to do it in the long term. The logical way to add services in the TCP/IP environment is one service = one client and one server on one port. It would be perfectly possible to devise a proper, lets say 'SFTP' protocol to be used on a TCP port, and then a, uhhhh, IMTP protocol to be used on some UDP port. NJE in itself is a pre-layering monster, were everything is mixed : you throw files and messages at one end, and see bits riding on a (sometimes virtual) wire at the other end. Multiplexing of application flows (messages and files), flow control, multiplexing of the bandwith (multiple data streams), routing, everything is done in the black box. This leads to some stupid things. An example : messages and files are handled by the same monolith, so, unless there are things I am not aware of, messages follow the same routes as files. While a multiple hop S&F strategy is fine for files, it does not make any sense for messages, to which it only adds delay and processing overhead while gaining nothing, since a message is dropped at the first down link encountered..... I am also wondering (but have no definitive idea) if it is wise to try to multiplex several data streams on a single TCP connection. The tradition seems to go in the opposite direction (99% of the FTP sessions involve at least two connections between a pair of hosts, for example), for the benefit of simplicity in the application protocols if for no other reason. Before I get flamed for what I did no say, let me restate what I said in the beginning : I am considering the *long* term, and I do understand that NJE-IP was needed to rapidly fix some real congestion problems. So this is not a critique for the developpers of NJE-IP, who of course were not the developpers of NJE, who in turn are probably not to be condemned given the time when work started on it. You are of course welcome to flame me on anything else.... /AF