On Wed, Sep 2, 2015 at 2:24 AM, KN <[email protected]> wrote: > I'm aware of netstrings, and in fact, my approach is similar. A frame > would be of the format [client_id][frame_data] . E.g. > > [123][ABCDEF] >
Ah, I see... You're missing a critical point about netstrings... they aren't just delimited, they are length-prefixed. Having that length at the beginning makes the value of netstrings clear... you read the length and then know exactly how much content to expect. > My question, though is, if I had no way to guarantee that the message will > not be split up into chunks arbitrarily, firing multiple read callbacks, > then my message could get broken up like this: > > [123][ABC] > [DEF] > > When I get [DEF] in my read callback, I would have no idea that this data > came from client 123. > It can get broken up arbitrarily by various pieces in the communication stack. So you have to have some buffering logic across the invocations of the libuv read callbacks to deal with all of the cases. I've done it for some closed-source code so, alas, I can't share the code but I'm happy go give you some guidance if you'd like. Cheers, John -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
