Re: [Taps] TCP components

[Joe Touch <[e-mail]>]

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