On 21 Feb 2008, at 18:25, Dan Wing wrote:
On 19 Feb 2008, at 18:43, Dan Wing wrote:
...
DCCP has an initiation handshake. It seems effective, to me,
to define SRV records that are something like this:
_foobar._dccp SRV 0 0 1234 server.example.com.
_foobar._dccp-udp SRV 0 0 1234 server.example.com.
and protocol foobar then tries both a native DCCP handshake
(to DCCP port 1234) and a DCCP-over-UDP handshake (to UDP
port 1234). We could do the native DCCP first and try
DCCP-over-UDP 100ms (or whatever you like) later.
This provides the incremental deployment we need (with
dccp-udp) and provides an easy path to real DCCP deployment
(where the UDP encapsulation is not necessary because there
are no meddling on-path IPv4 NATs).
Would this be feasible?
Sure, but is it needed? If you want DCCP-over-UDP encapsulation to
be seamless, then surely you need to try it every time a native
connection attempt fails. In that case, there's no need for
separate signalling.
What do you mean by 'separate signaling' -- are you referring to
the SRV record with _dccp-udp?
Yes.
I worry that the DCCP-UDP port might need to be different than the
DCCP-RAW port. Are you expecting them to always be the same? That
should be a reasonable assumption most of the time, but I worry it
might not work in some case.
I am expecting them to always be the same. My model is that a each
instance of the DCCP transport can either send packets natively over
IP, or tunnelled over UDP. Since it's a single transport instance,
the same port space would be used for encodings of the data.
--
Colin Perkins
http://csperkins.org/
