🚀 go-pugleaf

 In article <151@gipsy.UUCP>, ch@gipsy.UUCP (Christian Huitema) says:
>	Contrarily to the "usual" (IP - TCP - UDP) protocols, the OSI
>	architecture is strongly connection oriented. 
Not really! I always thought TCP was connection oriented. And now, we've
got a Connectionless Network Protocol (ISO DIS 8473) very similar to IP in
some ways!

>		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".
As you know, Christian, I'm working on this problem for a few months now. I
don't think you really need to pass down user-data in the "connect" call. This
needs to much changing in the existing code (even if this not *hudge* change).
The way I use it is passing user-data in a "setsockopt" call, prior to 
any action that may need it (before the "connect" when I'm about to send
a CR TPDU, and and after an "accept" when a CC is about to be sent.
I agree on the fact that *negociation* of connection parameters is the main
point. In fact, nobody tells you to use the "connect" and "accept" the way
Berkeley people did when coding TCP/IP. In particular, the "accept" doesn't
have to mean that connection is already established! I do use a new system
call (called "confirm", believe it or not !!) which tells the kernel if
Tranmsport Service User really accept the connection or not. That gives
me time to perform negociation through the "setsockopt/getsockopt" mechanism.

>	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.
Same point as above, "confirm" doesn't have to carry any user-data field in
it. I can always do a "getsockopt" with an appropriate flag to see if there
were any user-data in the previously received TPDU.
I let my "confirm" call as small as possible to make it portable easily. All
it does is saying to the kernel: "Right, Big Chief, I'm done with feeding you
with junk qos parameters! Build your TPDU and sent to my friend over the net!"

>	.... 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.
What about non-blocking read? I will not disagree: this is the worst point of
OSI Services. It may be worst (yet!?!) if you try to do a clean interface
flow control to regulate data passing. But maybe we could use some socket
state flags to let the user know if "message" is over or not.
One other problem you did not mention is the "expedited data" handling. I
still don't know if "out-of-band" facility is a good way to do it. Anyway,
the OOB stuff needs to be readapted to what OSI TS User is expecting.

Why don't you cross the road, and come over here? We could have a cup of tea 
(sorry, no beer herein!) and discuss about all these tiny vicious problems 
we've got in common: you are welcome at any time!


PS: Sorry for not speaking french to you, but I've been told that some
of other news readers didn't understand our dialect!

PPS:
>	However, I would like to know the opinion of Unix experts ... 
I'm not a really one but don't tell anybody, in case they think I am!


-- 
Sylvain "Panic Trap" Langlois		
UUCP Address:	(...!mcvax!vmucnam!lvbull!sylvain)
Postal Address:	BULL, PC 33/05, 68 route de Versailles,
		F-78430 Louveciennes, France.