Hi Kenton, For my real-time streaming application, currently the sender waits for a receipt from the other end and this works fine if the network RTTs are short. But in some cases, the sender is delayed for a longer period and eventually it crashes (I guess because of long network RTTs).
Reliability is not of high concern in my application. Can you provide some insight on designing something like getting an occasional ack of receipt from the receiver, if not the fire and forget approach (or UDP like)? Thanks, Abhishek On Tuesday, 1 December 2015 17:03:06 UTC-5, Kenton Varda wrote: > > That's a great question! > > The trouble with one-way messages is error handling: What if the message > never reaches its destination? Or what if it arrives but the recipient > application code crashes while handling it? The return message is there to > tell you that the messages was successfully received and processed. Failing > to check for errors is a common yet serious problem in any distributed > system or network protocol. > > Generally, the exception to this rule is in "streaming" cases, where the > sender sends *a lot* of messages but only needs occasional acknowledgment > of receipt. Potentially, 1000 one-way messages could be sent, followed by a > single two-way message to check how the receiver is doing. > > Streaming seems to fall into two sub-cases: > 1. Bulk transfer: E.g. a file upload. Reliable and ordered delivery is > important. Flow control is important. Latency hiccups are acceptable. > 2. Real-time (e.g. video chat): A late packet is worse than useless. The > receiving application can deal with missing and out-of-order packets, so if > a packet can't get through it should simply be dropped on the floor without > notifying the sender. > > Interestingly, (1) corresponds to TCP and (2) corresponds to UDP. But > neither is typical in RPC, at least in my experience. > > I would like to support bulk and real-time streams in Cap'n Proto, but at > present there is no timeline for adding them. > > For now, you will need to send regular request-response RPCs. Note that > the return values -- if the results are empty -- will always be smaller > than the original call, so it's unlikely that they'll "jam the server" > unless it is already running very close to capacity. > > -Kenton > > On Tue, Dec 1, 2015 at 12:49 AM, <[email protected] <javascript:>> wrote: > >> Hi all, I'm new to capnp. I love rpc but often I need to send some other >> messages, or in other words send some calls and really don't want the >> returns. For example, the server wants to broadcast a simple 'notify' >> message to all clients, but don't want to receive a lot of returns and jam >> the server. How should I do this? >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Cap'n Proto" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> Visit this group at http://groups.google.com/group/capnproto. >> > > -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/capnproto.
