🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: list.future-l
Article #4

Re: The fall of Bitnet

#4
From: Alain FONTAINE (Postmaster - NAD...
Date: Tue, 27 Feb 1990 15:06
45 lines
3413 bytes
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
Technical Details
Message-ID: <90Feb27.140136est.57720@ugw.utcs.utoronto.ca>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!BITNIC!FUTURE-L
References: Message of Tue, 27 Feb 90 13:40:51 O from <HANK@BARILVM>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!BITNIC!FUTURE-L
Date: Tue, 27 Feb 90 10:06:56 EST
Reply-To: BITNET Futures List <FUTURE-L@BITNIC.bitnet>
Sender: BITNET Futures List <FUTURE-L@BITNIC.bitnet>
From: "Alain FONTAINE (Postmaster - NAD)" <af@SEI.UCL.AC.BE>
Subject:      Re: The fall of Bitnet
To: UofToronto LAN redistribution <FUTURE-L@UTORGPU.uucp>
References:  Message of Tue, 27 Feb 90 13:40:51 O from <HANK@BARILVM>
Message-ID: <90Feb27.140136est.57720@ugw.utcs.utoronto.ca>
Newsgroups: list.future-l
Distribution: ut
Approved: devnull@gpu.utcs.toronto.edu