🚀 go-pugleaf

In article <34587@ucbvax.BERKELEY.EDU> sklower@ernie.Berkeley.EDU (Keith Sklower) writes:

> In article <5560054@hpindda.HP.COM> collin@hpindda.HP.COM (Collin Park) writes:
> }> 1.	Is it possible to translate TCP/IP <--> ISO8073 Cl4?
> }
> }In principle, no: tcp/ip has graceful release whereas 8073 has not.
> 
> and goes on to say
> 
> }...  there may be some
> }klugey way to get around it...  For example, if the 8073 class 4 (i'll
> }call it 'tp4' from now on) sends data and then waits for ALL data to
> }be acknowledged before sending the DR TPDU, then the close is
> }'graceful' from the sender's side.
> 
> This in fact is not true; ISO 8072 (the transport service specification)
> >>REQUIRES<< that if the transport provider on the remote end has
  ^^^^^^^^^^^^
	This is in practicality not true; ISO 8072, being a service definition
	(not "specification") has no conformance clause, and never will have
	one.  There is NO conformance to any service definition in OSI, because
	the architects of ISO/IEC JTC1/SC21 have declared (in their former
	lives as ISO TC97/SC21 and /SC16) that the service is abstract.

> data queued up for its consumer (session), (which has not yet been
		     ^^^^^^^^^^^^^^^^^^^^^
	The consumer isn't necessarily session, especially since we're
	talking about use of tp4 as a sort of tcp replacement.  Actually,
	it might even be possible to "conform" to 8072 by making a statement
	like this:

	  There is in my operating system a TS-user thingie which interfaces
	  to tp4 (on its lower end) and to applications accustomed to
	  operating over TCP/IP (on its higher end).  This "thingie"
	  always receives all data from the transport-entity instantly;
	  thus, my tp4 entity never has data queued awaiting receipt
	  by the "thingie".  The "thingie" also has a peep-hole into
	  network management and in particular knows how much data
	  have not been acknowledged by the peer tp4 entity.  When
	  the TCP-accustomed application tells it to disconnect 
	  gracefully, the "thingie" peeps at the "number of TPDUs not
	  yet acknowledged by remote" and waits for this number to
	  go to zero.  When all these data have been acked, the "thingie"
	  issues a T-disconnect.request to the local tp4 entity.

	This also circumvents the problem of "if data haven't been
	acked by the remote and the local tp4 entity receives a 
	disconnect.request from the TS-user, it shall toss those un-acked
	data and send the DR TPDU" -- since we simply delay giving the
	disconnect request until we KNOW that the remote has eaten all
	our data.

	Actually, by inserting this TS-user thingie I'm creating a site
	OUTSIDE of the tp4 entity where this "wait for all data to be acked"
	behavior is done, so it's not really being done inside the tp4
	entity.  (Actually, it's a transport-entity, not a "tp4 entity"...)

	So Keith is correct in saying that this behavior isn't legally
	part of ISO transport.  But can you bridge tcp to tp4?  I think
	that this lack-of-graceful-release need not be the factor that
	stops you.  The REAL problem is with directories and mapping 
	one style of addresses to the other....

> delivered), and the remote transport provider receives a disconnect
> request, then the remote transport provider MUST THROW AWAY all queued
> up data.							  

> Let's repeat that --  You know the remote guy has the received the data
> he know's he's got the data, but he can't tell you if his client has
> eaten it yet, and if it's still on the table when you the caterer leave
> the building, he's required to throw it in the garbage.

	As I hope I have made clear above, 
	 1) the layer service definitions do not have conformance clauses 
	    and thus are not subject to conformance tests;  
	 2) because of this, it is legitimate to bury the _interfaces_ 
	    and insert entities that allow OSI protocols to be used by
	    non-OSI-based applications (ftp, telnet, rlogin...)
	 3) there are still plenty of hurdles to making a practical
	    tp4/tcp bridge, but the graceful release issue, while being a
	    theoretical impediment, can (most probably) be creatively and
	    legally circumvented.

Hope this clarifies things....
------------------------------------------------------------------------------
This response does not represent the official position of, or statement by,
the Hewlett-Packard Company.  The above data is provided for informational
purposes only.  It is supplied without warranty of any kind.

collin park			Hewlett-Packard Company
collin%hpda@hplabs.hp.com	19420 Homestead Road -- MS 43LT
				Cupertino, CA  95014  USA