Re: [liblo] TCP receive bug on unreliable networks

Hi Camille,

I'm actually still working on this somewhat.  Not for lo_send(), but
for receiving, I started actually completely reworking the
lo_server_recv_raw_stream() function to behave in an more asynchronous
manner.

I was trying to figure out whether I could avoid reserving a big
buffer for each open socket, but it seems like it may be impossible.
Instead I'll just reserve a buffer only in cases where the full
message doesn't arrive in one shot.

Basically I'm trying to rewrite it to loop around back to select()
after each recv(), instead of looping around recv(), and save the
context if a full message couldn't be retrieved.  It's a bit
challenging though, so after a couple of hacking sessions I was still
trying to figure out the right way to organize it..

I don't feel comfortable doing a release with the loop around recv()
the way it is currently.  Once this is fixed though, I think it's the
last blocker for 0.27.

Steve

On Mon, Oct 1, 2012 at 8:22 AM, Camille Troillard <ca...@os...> wrote:
> 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
>
>
> ------------------------------------------------------------------------------
> Got visibility?
> Most devs has no idea what their production app looks like.
> Find out how fast your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219671;13503038;y?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel