Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83 ; site lvbull.UUCP Path: utzoo!linus!decvax!mcnc!philabs!cmcl2!seismo!mcvax!vmucnam!lvbull!sylvain From: sylvain@lvbull.UUCP (Sylvain Langlois RCG-ARS) Newsgroups: net.lan Subject: Re: OSI protocols in a socket environment Message-ID: <391@lvbull.UUCP> Date: Fri, 3-May-85 20:36:50 EDT Article-I.D.: lvbull.391 Posted: Fri May 3 20:36:50 1985 Date-Received: Tue, 7-May-85 20:37:07 EDT References: <151@gipsy.UUCP> Organization: BULL, Louveciennes, France Lines: 73 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.