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

[Harald Alvestrand <[e-mail]>]

On 07/24/2014 10:25 PM, Makaraju, Maridi Raju (Raju) wrote:
>
> */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. /*
>

The WebSocket protocol is not on-the-wire compatible with the 
DataChannel protocol.
This has not been a design goal, and I don't see any reason to make it one.

> *//*
>
> */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.

> *//*
>
> */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./*
>

/*PPID_OOB would make the compatibility problem worse, not better.*/
>
> *//*
>
> *//*
>
> */I then, rest my case! /**/J/**//*
>
> *//*
>
> */</Raju>/*
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb