On 6/19/2015 2:39 PM, Mohamed Oulmahdi wrote:
Of course, no one use a protocol without knowing the service it offers. When the application requests a TCP connection, it really request a reliable and ordered connection oriented service. The protocols primitives are used to each one to offer a part of this service.
My point is that the API primitives do define the service offered in this case. You can't use TCP without using OPEN; OPEN exists only because TCP is connection-oriented.
Similarly, SEND/RECEIVE are handled in-order and the byte order within each call is preserved - which indicates that this is a byte stream service. The lack of boundary marking within the SEND/RECEIVE calls - and the indication that SEND/RECEIVE block boundaries are not preserved - indicates that this is a byte stream service with no internal boundaries.
All of this can be gleaned from the API in section 3.8 of RFC 793. > The
difficulty occurs when several protocols are available, with mainly a certain service overlapping.
You're getting far ahead of the conversation, IMO. This document needs to start by explaining the services we already have before jumping into a "service of services" model.
I don't disagree with the goal, but it's impractical to develop a meta-interface when the base interface has not been described.
Joe _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
