- From: Iñaki Baz Castillo <ibc@aliax.net>
- Date: Wed, 7 May 2014 20:58:49 +0200
- To: tim panton <thp@westhawk.co.uk>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
2014-05-07 19:06 GMT+02:00 tim panton <thp@westhawk.co.uk>: >> The point here is not about reliability but about message-boundary. In >> TCP you must really close the socket is data is lost. That is not true >> (not for all the use-cases) in DataChannel since you always receive a >> complete message (may be you have lost some messages or they are not >> ordered, but what you receive is always a full message). >> > > Ok, so this is unreliabledc.send(myBigBlob); > where myBigBlob is probably bigger than the buffer on my IoT device? OK, I assume that myBigBlob will *entirely* arrive to the remote within a single STCP message (so in will be the event.data of the onmessage event) or it won't arrive at all. But it will never happen that just a fragment of myBigBlob arrives to the remote. Am I wrong? > That is knowable. This end knows how much buffer the far end said it still had free. > Throwing an error is reasonable. If the channel is reliable closing the channel is > the right thing to do. I don't entirely agree. If you get an exception (and assuming the socket is not closed) you can still send the data later. Different concepts here. A TCP non-blocking write() call can fail and that does not mean that the connection should be closed (instead it means that you must wait for the socket to become writeable, so same here). -- Iñaki Baz Castillo <ibc@aliax.net>
Received on Wednesday, 7 May 2014 18:59:39 UTC