Re: [liblo] TCP receive bug on unreliable networks

Hi Steve,

On 28 août 2012, at 21:59, Stephen Sinclair <rad...@gm...> wrote:

>> I am not sure if I understood correctly: so, this version of lo_send_async would call "send" and then return even if the call fails, am I right?
>> If so, it seems that this is a blocking approach, not asynchronous, because send does not necessarily return right away.
> 
> No no, I'm suggesting that lo_send_async() would return right away if
> it's not ready to send.  Using select() to check.  If it _is_ ready to
> send, it _still_ may not be able to send the whole message, and must
> call select() again and return if it's not ready.  In that case it
> still needs to be able to access previously unsent bytes.

Alright then, sounds good to me!


>> I believe one way to properly send messages asynchronously would be to use a message queue on which messages would be copied.
> 
> Yeah, either copied or just maintain pointers.  It might be nice to do
> it at the byte level and just queue things up in a big byte buffer,
> like you are suggesting, although I guess that means an error message
> if the buffer fills up.

Yes, samewise for a queue of messages I guess.


>> In fact, this queue does not even need to be implemented into liblo as long as lo_send is designed to loop over "send" until there is no more bytes to send or an error occurred.  A user could implement its own queue and run loop.  So I think lo_send_async is sugar for the future, we don't need it right now.
> 
> Right, except that means changing the semantics of lo_send(), which is
> why I was suggesting a new function.  Because currently lo_send() can
> only return 0 for success or -1 for error.  I suppose we could change
> it to use a positive number to indicate that some number of bytes
> still need to be sent -- this would be sort of backwards compatible
> since old code would error out if the whole message wasn't sent,
> assuming old code checked "!=0" rather than "<0" or "==-1".  However
> I'm not sure we have that guarantee.

Now I get it, sorry for the confusion.  I agree the new API lo_send_async would be necessary, and that we can't make the guarantee that users of lo_send switching to lo_send_async can expect the same function results, since the semantics are not the same.


>>> It's a bit more than I have time for at the moment however.  A loop
>>> around send() should do the trick for the synchronous API.  If we're
>>> tricky about it, in the bidirectional case we could use select() to
>>> read any incoming data while waiting to write.
>> 
>> I haven't though about this, thanks for pointing that out.
>> It's becoming quite complex.
> 
> Unfortunately.  I don't see a problem introducing new functions to get
> around current limitations however, we can always consider an API
> overhaul in the future for a major version update.

Yes, and thank you Steve for the great work on liblo!


Best,
Cam