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

["Makaraju, Maridi Raju (Raju)" <[e-mail]>]

In conclusion, I think websocket API supports zero length because websocket protocol supports zero-length data frames. So, it does not have the issue of ‘bufferedAmount’ discrepancy.


Yes, that is what I meant.
<Raju>
Ok, good. Websocket is not sending any dummy bytes, so bufferedAmount is always accurate.
I am still not convinced that to keep data channel API consistent with websocket API we need to introduce of dummy byte!?
How about keeping consistency of what goes on wire vs. what user sent? websocket preserves that, where as data channel won’t.
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.
IMHO, if doing PPID_OOB is more effort and can’t fit in webrtc 1.0 then it would be better to delay and do it in more proper way than taking a shortcut with PPID_EMPTY. With PPID_OOB approach underlying signaling protocol can negotiate OOB before using it; though such negotiation is not mandatory, but this approach allows such possibility.

I then, rest my case! ☺

</Raju>