On 4/7/2016 11:42 AM, Dale R. Worley wrote:
> [email protected] writes:
>> I agree - the current format from the text comes from the existing text
>> for TCP and SCTP in another draft. and I think we may need to work out
>> how to handle
>> [...]
>> I probably need help - I think there are different many ways in which UDP
>> uses ports. Offers from anyone on how to get started would be great.
>
> Even in TCP, the semantics of connection setup is more complicated that
> you'd think at first. If I have it correctly, it runs:
>
> Passive Active
> Endpoint Endpoint
>
> Create socket
> Bind socket to listening address
There's a step here where you get to set the limit on how many pending
connection requests can be allowed (the listen() call), but that's an
OS-ism IMO, not a protocol or API issue.
> Activate listening
>
> Create socket
optionally bind to local address
> Connect
>
> Incoming connection event
> Accept connection
an optional parameter to this accept call involves whether the remote
socket pair is specified or not.
> At least in the protocol, it's possible for both endpoints to be active,
> but they have to have prior agreement regarding the addresses and ports
almost - they only need to agree on the port one one side exactly; in
both cases, the addresses need to reach each other but could be one of
any number of addresses on the machine.
E.g.:
A calls B.alpha using dest port 80
while
B calls A.omega using source port 80
> and send their initial packets within one RTT of each other, so I don't
> know if that possibility is ever used in practice.
It happens routinely if you end up calling yourself.
> Or whether the
> Berkeley sockets API supports it.
It should, as per above.
> OTOH, the TAPS work might not be attempting to capture the semantics of
> connection setup.
It had better, IMO.
> The process for UDP is not much simpler. My memory is:
>
> Passive Active
> Endpoint Endpoint
>
> Create socket
> Bind socket to listening address
you only need to bind to a port; the address can float
you can optionally also lock the remote address using the "connect"
call, even though it doesn't issue a connection.
> Create socket
> Send-to -or- Connect, then Send
or bind too. Same reasons - you can pin the local or remote socket pair.
> Incoming connection event
> Connect (in the TAPS paradigm)
IMO, this should be removed. There can't be state associated with UDP.
> Incoming packet event
> Receive packet
The receive packet for UDP passes more information than for TCP; in UDP,
you need to indicate where the message came from too.
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
