🚀 go-pugleaf

..............................................................................

While trying to implement the OSI transport and session layer in a "socket"
environment, we encountered several problems, that I suppose may have been
solved elsewhere.

1) Connection phase:
	Contrarily to the "usual" (IP - TCP - UDP) protocols, the OSI
	architecture is strongly connection oriented. Each connection should
	be acknowledged. Connection request and connection acknowledge may
	carry "user" data (e.g. layer N+1 connection rq/ak). Connection
	acknowledge has an end to end significance, and carry the result of
	a negociation (e.g. end to end throughput class, message length,
	etc). Thus, we propose the following improvements:
		1) Allow the passing of (limited size) user data in the
		"CONNECT" primitive.
		2) create a "CONFIRM" primitive, similar to "CONNECT", that
		would be invoiced after "ACCEPT".
	Between the invocation of ACCEPT and CONNECT, the user could
	"SET_SOCK_OPT" to fix negociated parameters. The "CONNECT" primitive
	should return the "user_data" sent within the CONFIRM.

2) Transfer phase:
	The OSI connections enables the users to transmit "messages". The
	frontiers of these messages are part of the syntax, and should be
	preserved during the transfer.
	User messages above the transport layer are not limited in size. More
	precisely, their size is only limited by an end to end agreement
	between the applications. Exemples of likely sizes are 1 to 3 Kbytes
	for "Teletex", 100 Kbytes to 1 or 2 Mbytes for image transfers.
	This messages will be truncated into manageable size segments at the
	transport level.

	If we were writing the OSI protocols as v7 character oriented
	drivers, this would not be a problem. It would be sufficient to
	accumulate the incoming segments (OSI connections preserve their
	order), within a "read", into the "u_area". The end to end
	negociation of message sizes implies that the user programs would
	be able to forecast the maximum size of the messages, and pass the
	correct arguments to the "read" command. They will be happy if they
	are only waken up after an "end of message" segment has been
	received.

	This is less easy to do in a socket environment. The "correct" thing
	would be to accumulate all segments into a chain of "mbufs" until an
	"end-of-message" indication has been received, and then pass the
	whole chain to the upper layer. But this implies that, depending
	only of the application process, a huge amount of memory would have
	to be stored at intermediate levels. It would be much "nicer" to
	pass the incoming segments to the upper levels, along with an
	"end-of-message" mark. A possible way would be to terminate a chain
	of "mbufs" by a pointer "(int)m_next = -1" if more data is excepted,
	or "m_next = 0" if this is ths last segment of a message.

There are also some minor problems when implementing all the features of the
OSI session layer, e.g. checkpoints or activities. However, I would like to
know the opinion of Unix experts about these two extensions, i.e "confirm"
and "end-of-message mark".

Christian HUITEMA			()!mcvax!inria!gipsy!ch
GIPSI/INRIA
Rocquencourt BP105
78153 Le Chesnay - FRANCE