Re: [rtcweb] Sending of zero-length messages over data channels

[Justin Uberti <[e-mail]>]

On Mon, Aug 4, 2014 at 11:08 AM, Makaraju, Maridi Raju (Raju) <
[e-mail]> wrote:

>
>
>
>
> *>IMHO opinion, sending such a dummy byte may have other consequences:*
>
> 1.      *>App is not aware of what’s going on? send() probably meant to
> be called >with non-empty data, but some error leg could have caused it
> become >empty, but still a byte will be sent out!!*
>
> 2.      *>Debugging becomes bit more complex and not intuitive. WebRTC is
> >already complex, why add more complexity?*
>
> 3.      *>Interop issues. The more the exceptions the more the interop
> issues you >see as some implementations may overlook these or implement
> them >later.*
>
>
>
> *>It’s usually a bad idea to send a dummy byte on wire, without the
> application >direct involvement.*
>
>
> >I recommend spending some time with Wireshark looking at actual traces
> >before making any such statement. Many protocols have dummy bytes, for
> >many different reasons.
>
>  *<Raju2> *
>
> *I am afraid there is some confusion about my comment and as a result we
> may be talking about dummy bytes at 2 different levels: app level and
> underlying protocol level.*
>
> *I am aware of many protocols using reserved bits, bytes, padded
> bits/bytes, protocol-level heartbeats/PING-PONGs (SCTP heartbeats use of
> opaque data). In all these cases the mechanism is built into the protocol
> below app-level protocol itself with no direct involvement of
> application-level protocol. My comment was in the context of
> application-level protocol. *
>
> *If app calls send() 3 times with data “abc”, “” (empty/null data with
> size 0) and then “xyz” then on the wire in the application-level payload
> you see “abc” <dummy byte> “xyz”.*
>
> *So, can you please point to me a protocol where this kind of dummy
> byte(s) are inserted in between application payload?*
>
>
>
> *Btw, If you leave the app choice to send the byte (using OOB_PPID) then
> there is a possibility for the app to send 256 distinct values instead of
> browser hard-coding the byte to zero always, which just conveys a single
> value.*
>
>
>
> *</Raju2>*
>
>
>

What value would this provide to justify the increased complexity?


>
> *>PPID_OOB would make the compatibility problem worse, not better.*
> *<Raju2>*
>
> *I would appreciate if you can provide reasons on why PPID_OOB making
> compatibility worse?*
>
> *With PPID_OOB, apps have a choice to negotiate (this negotiation is like
> any other negotiation for webrtc.) and use this option. PPID_EMPTY option
> seems to be enabled always and no way to turn-off. *
>
> *Without an option to turn off PPID_EMPTY, you will get into more
> compatibility issues as some webrtc implementations may not implement it on
> day one; a native client could be using an interim version of a popular
> webrtc lib; or it might be using its own webrtc lib, in which case we can’t
> expect it to implement all these later-adders in a timely manner.*
>
>
> I doubt this will be a real-world problem, given that the protocol is
still evolving and all implementations need to keep up, but if this turns
out to be an issue we can negotiate it in SDP.