So,
From all the thread so far
* I have some ideas of what RTP-like applications want. I'm not sure
there is a need to send/receive a 0-byte Data packet as a way to make
keep-alives happen. (To me, it seems RTP-NOP packets should not be
re-encoded as 0-byte Data packet).
* I suggest the standard send/receive calls are not allowed to send null
packets (although RFC4340 does allow it, is this right?).
* One option may be to call a socket function to ask DCCP to generate
packets at least every "x" seconds. *IF* that's all that is needed that
seems to me to be OK. If an APP (e.g. RTP) want to explicitly send
something - then it could actually send a packet across the API.
* The last part is what should appear on the wire: IMHO, I think someone
now needs to look at the Specs and how a receiver handles this in DCCP -
to figure out what a receiver does when it gets a 0-byte DCCP Data
packet, and therfore what the side-effects are. If these are in any way
"odd" then we should be using a different packet format for this purpose
(rather than over-loading an existing packet type).
Someone here can look at the final point, but that's not going to happen
for a wee while (into April)
Gorry
Phelan, Tom wrote:
Hi Gorry,
See inline...
Tom P.
-----Original Message-----
From: Gorry Fairhurst [mailto:gorry@xxxxxxxxxxxxxx]
Sent: Tuesday, March 27, 2007 10:58 AM
To: Arjuna Sathiaseelan
Cc: dccp@xxxxxxxx
Subject: Re: Why do we have or should have keep-alive packets?
Arjuna Sathiaseelan wrote:
Dear Tom,
OK, so at least two of us agree that DCCP SHOULD NOT generate
DCCP-Data packets on its own (zero length or otherwise) :-).
:)
So nobody has yet explained why DCCP can't do this for it's own purpose
(although I am not advocating this).
[Tom P.] I'm not saying that DCCP can't do keep-alives, just that it
shouldn't use zero-length DCCP-Data packets for that purpose. DCCP-Data
packets are supposed to be for user data, usurping them for
DCCP-specific uses corrupts that.
Therefore it seems to me that applications MAY use zero-length packets
as they see fit. The question left is "is RTP an application?" To
me, RTP has many more of the characteristics of a transport protocol
>> than an
application, but it is consistently used over some transport protocol,
so what is it?
I think this has two perspectives:
1) From the RTP's point of view, it has characteristics of a transport
protocol, and infact RTP is a transport protocol for real-time
applications.
2)From the underlying transport protocol which carries the RTP
packets, RTP
would be considered as an application layer entity?
So, the model I think that Colin has in mind for RTP over DCCP (chime
in
if I get it wrong, Colin) is that a real-time application gives data
to
RTP, RTP wraps that data in RTP packets and gives that to DCCP, who
wraps the RTP packets in DCCP packets. So from DCCP's point of view,
RTP is the application, and the (real) application has no way of
directly sending DCCP packets. That says that RTP MAY send
zero-length
packets.
True. I think so too.
I got all that, until the last sentence, which didn't seem to make any
sense at all. HOW can an application (or upper layer) send zero bytes of
data ... AFAIK, we no interfaces to do this, even if it were sensible,
which I doubt.
[Tom P.] Well, one way would be to have an ioctl or sockopt to do it.
Another, riskier, way is to interpret a write with zero length as a
command to send a zero-length packet. The protocol has the capability,
making an API for doesn't seem like a big deal :-).
One question that I still have is who is responsible for recognizing
idle and sending something? Is it the RTP stack? Or should the app
send a NOP packet that the RTP stack translates to a zero-length
packet?
No!
[Tom P.] No what? App send a NOP that gets translated? That seems
silly to me too.
I am trying to find answers to these questions too. Maybe Colin is the
right
person who can shed some light :).
Regards
Arjuna
[snipped]
?
Gorry
