Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!bu.edu!bu-it.bu.edu!kwe
From: kwe@bu-it.bu.edu (Kent England)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Advantages/Disadvantages Of TCP+Router Vs. Straight X.25
Message-ID: <74027@bu.edu.bu.edu>
Date: 6 Feb 91 17:30:10 GMT
References: <38836@cup.portal.com>
Sender: news@bu.edu.bu.edu
Reply-To: kwe@bu.edu
Organization: Boston University Information Technology
Lines: 56

In article <38836@cup.portal.com>, Will@cup.portal.com (Will E Estes) writes:

> Newsgroups: comp.protocols.iso,comp.protocols.tcp-ip
> Subject: Advantages/Disadvantages Of TCP+Router Vs. Straight X.25
> Date: 4 Feb 91 02:09:29 GMT
> 
> I would like to get opinions on pros and cons for setting up an
> Internet.  The two setups are:
> 
> 1) All sites on the internet have routers that attach to a public
> data network and use TCP/IP to communicate between nodes on the net.
> 
> 2) All sites on the internet connect directly to an X.25 network,
> and any client-server applications between two sites are written
> directly to an X.25 API or to some software abstraction that is
> written on top of X.25.
> 

	The wording is kind of hard to interpret, since I think "site"
is used when "host" might be what is meant, but nonetheless ...

	I would decouple internet issues from application API issues
and loosen up on the "either/or" tone and take an attitude of "one or
more". 

	If I had the choice of APIs to write to for client-server
applications, it would be a session-style API and/or an RPC API that
offers me virtual circuit streams-of-data service, simple unreliable
messaging, and a robust transaction protocol that would be able to run
on TCP/IP or OSI-IP or 802.2 as part of the operating system I was
using.

	If I didn't have an OS that offered me a good session or RPC
API, then I would still write that interface myself and write a lower
level interface to TCP/IP and one to X.25.  Then if I wanted more
transport options in future, I wouldn't have to rewrite my
client-server code, only yet another transport option for my session.

	The idea is to layer intelligently, hide what lower level
information can be hidden, but write the API such that it anticipates
the wide variety of transport services that it might have to use
(connectionless, connection-oriented, high-bandwidth/low-latency,
low-bandwidth/hi-latency, ...).

	As far as internet architectures go, allow for multiple
protocols and overlapping transition periods.  Keep your LAN and WAN
technologies decoupled by using routers or capable bridges.  Design
with multi-protocol hosts and servers in mind.  Give your users
options, not mandates.

	X.25 is a WAN option to use public nets over the use of
private lines, nothing more.  I don't care for it as an alternative
for available LAN technology.  It has been more than four years since
I heard anyone seriously talk about doing that.  :-)

	--Kent