liblo-devel Mailing List for LibLO

On Fri, Jun 8, 2012 at 9:45 AM, Camille Troillard <ca...@os...> wrote:
> Hi Steve,
>
>
>> Absolutely right, fixed.
>
> We're almost there!
>
> In address.c:217 the memory occupied by the lo_address should be cleared, or else the test at server.c:665 will be inconsistent (a->host != NULL).  I suggest the following fix:
>
> void lo_address_free_mem(lo_address a)
> {
>    if (a) {
>        if (a->host)
>            free(a->host);
>        if (a->port)
>            free(a->port);
>        if (a->ai_first)
>            freeaddrinfo(a->ai_first);
>        if (a->addr.iface)
>            free(a->addr.iface);
>
>        memset(a, 0, sizeof(struct _lo_address)); // clear the memory
>        a->socket = -1;
>    }
> }
>
>
> With this, it works fine on side (with external process connecting and disconnecting).

Okay, committed this.  I'm surprised I didn't get a segfault ;)

thanks again,
Steve

Hi Steve,


> Absolutely right, fixed.

We're almost there!

In address.c:217 the memory occupied by the lo_address should be cleared, or else the test at server.c:665 will be inconsistent (a->host != NULL).  I suggest the following fix:

void lo_address_free_mem(lo_address a)
{
    if (a) {
        if (a->host)
            free(a->host);
        if (a->port)
            free(a->port);
        if (a->ai_first)
            freeaddrinfo(a->ai_first);
        if (a->addr.iface)
            free(a->addr.iface);

	memset(a, 0, sizeof(struct _lo_address)); // clear the memory
        a->socket = -1;
    }
}


With this, it works fine on side (with external process connecting and disconnecting).


>> - I saw you added support for correct reading of TCP stream in the commit "Retry stream recv until all bytes are read.", that good because I won't have to merge my changes for this (it was almost the same code).  Regarding this issue, I would love to know your opinion about one my previous emails.  I just wanted to let you know that the way it is implemented will defeat liblo's non-blocking reading as it could potentially block on recv, but I guess it is alright at the moment!
> 
> Yes, I'll modify it to track blocking behaviour.

Great!
Please let me know if you need help.



Best,
Cam

On Fri, Jun 8, 2012 at 4:41 AM, Camille Troillard <ca...@os...> wrote:
> Hey Steve,
>
> Thanks for the commits!
>
> - The commit "Address removes TCP socket from source server's list if send fails." does not work for me.  I have a crasher, with the following backtrace when the server closes its connection.
>
> #0      0x1000a7706 in lo_address_free_mem at address.c:220
> #1      0x1000ae8d0 in lo_server_del_socket at server.c:1162
> #2      0x1000addcc in lo_server_recv_raw_stream at server.c:811
> #3      0x1000ae58b in lo_server_recv at server.c:1092
>
>
> I am not entirely sure of this line in server.c:1162
>    lo_address_free_mem(&s->sources[s->sockets[i].fd]);
>
> Since the variable has been used to iterate, I feel it should not be used anymore.

Absolutely right, fixed.

> - I saw you added support for correct reading of TCP stream in the commit "Retry stream recv until all bytes are read.", that good because I won't have to merge my changes for this (it was almost the same code).  Regarding this issue, I would love to know your opinion about one my previous emails.  I just wanted to let you know that the way it is implemented will defeat liblo's non-blocking reading as it could potentially block on recv, but I guess it is alright at the moment!

Yes, I'll modify it to track blocking behaviour.  Sorry I didn't get
to those other ones yet, these days I seem to be able to do only one
thing at a time :)

Steve

Hey Steve,

Thanks for the commits!

- The commit "Address removes TCP socket from source server's list if send fails." does not work for me.  I have a crasher, with the following backtrace when the server closes its connection.

#0	0x1000a7706 in lo_address_free_mem at address.c:220
#1	0x1000ae8d0 in lo_server_del_socket at server.c:1162
#2	0x1000addcc in lo_server_recv_raw_stream at server.c:811
#3	0x1000ae58b in lo_server_recv at server.c:1092


I am not entirely sure of this line in server.c:1162
    lo_address_free_mem(&s->sources[s->sockets[i].fd]);

Since the variable has been used to iterate, I feel it should not be used anymore.


- I saw you added support for correct reading of TCP stream in the commit "Retry stream recv until all bytes are read.", that good because I won't have to merge my changes for this (it was almost the same code).  Regarding this issue, I would love to know your opinion about one my previous emails.  I just wanted to let you know that the way it is implemented will defeat liblo's non-blocking reading as it could potentially block on recv, but I guess it is alright at the moment!


Best,
Cam






On 8 juin 2012, at 06:17, Stephen Sinclair wrote:

> I just made a few commits that deal with these bugs.
> Please re-test!
> 
> I also added an example of an "echo" server which works for me on
> Ubuntu and OS X.
> 
> Steve
> 
> On Thu, Jun 7, 2012 at 12:23 PM, Stephen Sinclair <rad...@gm...> wrote:
>> Trying to write an echo-responder example using liblo, I'm getting a
>> "Bad file descriptor" error when recv()ing from the same socket that
>> connect() was made on.
>> 
>> I'm not sure why this is happening, but I think it's related.  It's
>> weird because poll() indicates that the socket is ready for read, but
>> then recv() returns an error.
>> 
>> This didn't appear when I was testing the bidirectional communicating
>> using threads, rather than two processes.
>> 
>> (Stupidly, the return code for recv() wasn't even being checked.  I'll
>> have to go over the code to look for cases like that.  In general I
>> think there is an assumption in the code that send() and recv()
>> successfully deal with a whole message, which works alright for UDP
>> but for TCP it should allow for partial transactions and re-try.)
>> 
>> Steve
>> 
>> On Thu, Jun 7, 2012 at 6:41 AM, Camille Troillard <ca...@os...> wrote:
>>> Hi Steve,
>>> 
>>> 
>>> On 6 juin 2012, at 22:42, Stephen Sinclair wrote:
>>> 
>>>>> Here is the sequence of events:
>>>>> 
>>>>> 1- The server is opened waiting for connections.
>>>>> 2- The client connects to the server and sends a bunch of messages.
>>>>> 3- The server is closed.
>>>>> 3a- At this moment, it causes an error "Message too large or read failed." at line 805 in server.c.  The read length is actually 0, which indicates that the server socket has been closed, but there is no error.
>>>>> 4- The server is launched again, probably on another port.
>>>>> 5- Although the server is up, and receives and sends messages with the client, its replies (messages sent from the server to the client) are not received.
>>>> 
>>>> Okay, excellent testing, thanks.  I didn't thoroughly test opening and
>>>> closing connections more than once, it certainly deserves attention.
>>>> I can probably figure out what you mean by your "echo responder" but
>>>> if you post the code it might speed things up.
>>> 
>>> Sure, here it is:
>>> https://github.com/tuscland/osc-echo-example
>>> 
>>> 
>>>> I'll try to get to your other messages soon too.
>>> 
>>> Thanks.
>>> 
>>> 
>>> Best,
>>> Cam
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> liblo-devel mailing list
>>> lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
> 

I just made a few commits that deal with these bugs.
Please re-test!

I also added an example of an "echo" server which works for me on
Ubuntu and OS X.

Steve

On Thu, Jun 7, 2012 at 12:23 PM, Stephen Sinclair <rad...@gm...> wrote:
> Trying to write an echo-responder example using liblo, I'm getting a
> "Bad file descriptor" error when recv()ing from the same socket that
> connect() was made on.
>
> I'm not sure why this is happening, but I think it's related.  It's
> weird because poll() indicates that the socket is ready for read, but
> then recv() returns an error.
>
> This didn't appear when I was testing the bidirectional communicating
> using threads, rather than two processes.
>
> (Stupidly, the return code for recv() wasn't even being checked.  I'll
> have to go over the code to look for cases like that.  In general I
> think there is an assumption in the code that send() and recv()
> successfully deal with a whole message, which works alright for UDP
> but for TCP it should allow for partial transactions and re-try.)
>
> Steve
>
> On Thu, Jun 7, 2012 at 6:41 AM, Camille Troillard <ca...@os...> wrote:
>> Hi Steve,
>>
>>
>> On 6 juin 2012, at 22:42, Stephen Sinclair wrote:
>>
>>>> Here is the sequence of events:
>>>>
>>>> 1- The server is opened waiting for connections.
>>>> 2- The client connects to the server and sends a bunch of messages.
>>>> 3- The server is closed.
>>>> 3a- At this moment, it causes an error "Message too large or read failed." at line 805 in server.c.  The read length is actually 0, which indicates that the server socket has been closed, but there is no error.
>>>> 4- The server is launched again, probably on another port.
>>>> 5- Although the server is up, and receives and sends messages with the client, its replies (messages sent from the server to the client) are not received.
>>>
>>> Okay, excellent testing, thanks.  I didn't thoroughly test opening and
>>> closing connections more than once, it certainly deserves attention.
>>> I can probably figure out what you mean by your "echo responder" but
>>> if you post the code it might speed things up.
>>
>> Sure, here it is:
>> https://github.com/tuscland/osc-echo-example
>>
>>
>>> I'll try to get to your other messages soon too.
>>
>> Thanks.
>>
>>
>> Best,
>> Cam
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Trying to write an echo-responder example using liblo, I'm getting a
"Bad file descriptor" error when recv()ing from the same socket that
connect() was made on.

I'm not sure why this is happening, but I think it's related.  It's
weird because poll() indicates that the socket is ready for read, but
then recv() returns an error.

This didn't appear when I was testing the bidirectional communicating
using threads, rather than two processes.

(Stupidly, the return code for recv() wasn't even being checked.  I'll
have to go over the code to look for cases like that.  In general I
think there is an assumption in the code that send() and recv()
successfully deal with a whole message, which works alright for UDP
but for TCP it should allow for partial transactions and re-try.)

Steve

On Thu, Jun 7, 2012 at 6:41 AM, Camille Troillard <ca...@os...> wrote:
> Hi Steve,
>
>
> On 6 juin 2012, at 22:42, Stephen Sinclair wrote:
>
>>> Here is the sequence of events:
>>>
>>> 1- The server is opened waiting for connections.
>>> 2- The client connects to the server and sends a bunch of messages.
>>> 3- The server is closed.
>>> 3a- At this moment, it causes an error "Message too large or read failed." at line 805 in server.c.  The read length is actually 0, which indicates that the server socket has been closed, but there is no error.
>>> 4- The server is launched again, probably on another port.
>>> 5- Although the server is up, and receives and sends messages with the client, its replies (messages sent from the server to the client) are not received.
>>
>> Okay, excellent testing, thanks.  I didn't thoroughly test opening and
>> closing connections more than once, it certainly deserves attention.
>> I can probably figure out what you mean by your "echo responder" but
>> if you post the code it might speed things up.
>
> Sure, here it is:
> https://github.com/tuscland/osc-echo-example
>
>
>> I'll try to get to your other messages soon too.
>
> Thanks.
>
>
> Best,
> Cam
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hi Steve,


On 6 juin 2012, at 22:42, Stephen Sinclair wrote:

>> Here is the sequence of events:
>> 
>> 1- The server is opened waiting for connections.
>> 2- The client connects to the server and sends a bunch of messages.
>> 3- The server is closed.
>> 3a- At this moment, it causes an error "Message too large or read failed." at line 805 in server.c.  The read length is actually 0, which indicates that the server socket has been closed, but there is no error.
>> 4- The server is launched again, probably on another port.
>> 5- Although the server is up, and receives and sends messages with the client, its replies (messages sent from the server to the client) are not received.
> 
> Okay, excellent testing, thanks.  I didn't thoroughly test opening and
> closing connections more than once, it certainly deserves attention.
> I can probably figure out what you mean by your "echo responder" but
> if you post the code it might speed things up.

Sure, here it is:
https://github.com/tuscland/osc-echo-example


> I'll try to get to your other messages soon too.

Thanks.


Best,
Cam

On Tue, Jun 5, 2012 at 8:34 AM, Camille Troillard <ca...@os...> wrote:
> Hi Stephen,
>
> I have written a simple TCP echo responder to test the new bi-directional feature of liblo.
> First of all thank you for taking care of this problem, I had nothing to change in my application.
>
> It seems to work correctly, however I have noticed a small problem:
>
> Here is the sequence of events:
>
> 1- The server is opened waiting for connections.
> 2- The client connects to the server and sends a bunch of messages.
> 3- The server is closed.
> 3a- At this moment, it causes an error "Message too large or read failed." at line 805 in server.c.  The read length is actually 0, which indicates that the server socket has been closed, but there is no error.
> 4- The server is launched again, probably on another port.
> 5- Although the server is up, and receives and sends messages with the client, its replies (messages sent from the server to the client) are not received.
>
> I have nothing to test with other than my echo responder.
> I believe the responder is working properly, so I would be interested to know if anyone is able to reproduce this problem.
>
> I will be happy to provide the source code for the echo responder.
> It has been purposely implemented without liblo and works on Mac OS X.

Okay, excellent testing, thanks.  I didn't thoroughly test opening and
closing connections more than once, it certainly deserves attention.
I can probably figure out what you mean by your "echo responder" but
if you post the code it might speed things up.

I'll try to get to your other messages soon too.

Steve

Hi Stephen,

I have written a simple TCP echo responder to test the new bi-directional feature of liblo.
First of all thank you for taking care of this problem, I had nothing to change in my application.

It seems to work correctly, however I have noticed a small problem:

Here is the sequence of events:

1- The server is opened waiting for connections.
2- The client connects to the server and sends a bunch of messages.
3- The server is closed.
3a- At this moment, it causes an error "Message too large or read failed." at line 805 in server.c.  The read length is actually 0, which indicates that the server socket has been closed, but there is no error.
4- The server is launched again, probably on another port.
5- Although the server is up, and receives and sends messages with the client, its replies (messages sent from the server to the client) are not received.

I have nothing to test with other than my echo responder.
I believe the responder is working properly, so I would be interested to know if anyone is able to reproduce this problem.

I will be happy to provide the source code for the echo responder.
It has been purposely implemented without liblo and works on Mac OS X.


Best,
Camille



On 4 juin 2012, at 06:58, Stephen Sinclair wrote:

> To quote George R. R. Martin's acknowledgements in A Feast for Crows:
> 
> "This one was a bitch."
> 
> But it works!  Or seems to at least.  It took me 3 goes at it before I
> understood what was missing.  It's going to need a lot more testing
> than I have given it so far, particularly with multiple connections.
> Getting bidirectional TCP was tricky because the required information
> for sending replies was discarded early in the connection process.  I
> had to add an array of lo_address structures to the server to save the
> "sources" of each connection after accept()ing them.
> 
> Also, on sending a reply, it was necessary to add the sending socket
> to the "from" server's socket list.  I ended up having to modify the
> call signature for dispatch_data() and dispatch_method() just to pass
> the socket information through to the method handler so that the
> correct source could be determined.
> 
> So this patch increased yet again some of the cross-talk between
> modules, unfortunately exposing some internal functions to the ABI.
> (I like to keep internal functions static if possible, hate moving
> them to lo_internal.h)
> 
> Anyways, as always, please test.  Hopefully with this feature out of
> the way I can move on to fixing remaining bugs and get a release out
> the door.
> 
> Steve
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hello Stephen,

I am resurrecting an old discussion.
To refresh your memory, the problem was the following:

1- using liblo, TCP client sends data to a TCP server.
2- client stops sending data.
3- the server is closed.
4- now we try to open the server again on the same port.
5- -> results in "error port in use" and the server can not be open anymore.


The server can be opened again only if we wait enough (about 1 minute), or this scenario happens:

1- using liblo, TCP client sends data to a TCP server.
2- client stops sending data.
3- the server is closed.
3b- the client sends a message to the closed server -> result in an expected error.
4- now we try to open the server again on the same port.
5- -> the server is opened again.


A friend gave me what looks like a good solution:
Set the SO_REUSEADDR flag on the server socket.
So far, this works well for me and fixes a behavior I considered as a bug since a long time.

Here is some documentation about this:

> I've come across : Beej's Guide to Network Programming
> 
> 	http://beej.us/guide/bgnet/
> 
> which seems quite good.  It's up to date, ie it covers IPv4 and IPv6, and emphasises writing code that accommodates either.
> 
> Still working through it, but I came across a bit (at the bottom of page 19 in section 5.3) that may help re Osculator reporting a 'port in use' error after un-pausing.  The author also mentions that the problem goes away after a minute or so, which matches what you said.


More specifically:

>> Sometimes, you might notice, you try to rerun a server and bind() fails, claiming "Address already in use." What does that mean? Well, a little bit of a socket that was connected is still hanging around in the kernel, and it's hogging the port. You can either wait for it to clear (a minute or so), or add code to your program allowing it to reuse the port, like this:
>> 
>> int yes=1;
>> //char yes='1'; // Solaris people use this
>> 
>> // lose the pesky "Address already in use" error message
>> if (setsockopt(listener,SOL_SOCKET,SO_REUSEADDR,&yes,sizeof(int)) == -1) {
>>     perror("setsockopt");
>>     exit(1);
>> } 



And the patch is attached...


Best,
Cam

Hi Steve,

Sorry for the late answer.


On 30 avr. 2012, at 21:37, Stephen Sinclair wrote:

> On Sat, Apr 28, 2012 at 9:42 AM, Camille Troillard
> <ca...@os...> wrote:
>> Hello,
>> 
>> In message.c at line 942, lo_arg_pp_internal is called with the last argument (bigendian) set to 0.
>> This causes values to print incorrectly on little endian cpu based computers.
> 
> That line is:
> 
> lo_arg_pp_internal(m->types[i], d, 1);
> 
> Do you mean "set to 1"?

Yes, in the liblo trunk, lo_arg_pp_internal is called with the last argument being 1.
I believe it should be 0 (see attached diff)


> My understanding is that lo_arg_pp needs to be told whether the data
> has been converted from network order or not.  So lo_arg_pp() calls it
> with bigendian=0, since the data has presumably already been
> deserialised.  Whereas lo_message_pp calls it with bigendian=1, since
> inside the lo_message it points to serialised data?
> 
> However, this seems to be not true, as you point out.  Data pointed to
> by lo_message is always already converted to native order, so it
> should always be called with bigendian=0 even in lo_message_pp.
> Confusing. It would seem only useful when referring to serialised
> data.  I guess I'll need to test on little and big endian machines to
> be sure.  Fortunately I still have access to a ppc mac.

Did you find something regarding this issue?
I'm sorry, I don't have access to a ppc mac ...


Best,
Cam

Hi Stephen,

This is great, thank you for this big patch!


Best,
Cam


On 4 juin 2012, at 06:58, Stephen Sinclair wrote:

> To quote George R. R. Martin's acknowledgements in A Feast for Crows:
> 
> "This one was a bitch."
> 
> But it works!  Or seems to at least.  It took me 3 goes at it before I
> understood what was missing.  It's going to need a lot more testing
> than I have given it so far, particularly with multiple connections.
> Getting bidirectional TCP was tricky because the required information
> for sending replies was discarded early in the connection process.  I
> had to add an array of lo_address structures to the server to save the
> "sources" of each connection after accept()ing them.
> 
> Also, on sending a reply, it was necessary to add the sending socket
> to the "from" server's socket list.  I ended up having to modify the
> call signature for dispatch_data() and dispatch_method() just to pass
> the socket information through to the method handler so that the
> correct source could be determined.
> 
> So this patch increased yet again some of the cross-talk between
> modules, unfortunately exposing some internal functions to the ABI.
> (I like to keep internal functions static if possible, hate moving
> them to lo_internal.h)
> 
> Anyways, as always, please test.  Hopefully with this feature out of
> the way I can move on to fixing remaining bugs and get a release out
> the door.
> 
> Steve

Hello Stephen,

I come back on this issue because I think there is an issue with how liblo sends and receives TCP data.

I initially thought that when TCP is used, doing a recv or a send would eventually receive or send all the data.  This is how liblo works at the moment.


But this is not true, you have to iterate until all the data is received or sent.
See: http://stackoverflow.com/questions/1837444/tcp-connection-seems-to-receive-incomplete-data

> The recv function can receive as little as 1 byte, you may have to call it multiple times to get your entire payload. Because of this, you need to know how much data you're expecting. Although you cansignal completion by closing the connection, that's not really a good idea.
> 
> Update:
> 
> I should also mention that the send function has the same conventions as recv: you have to call it in a loop because you cannot assume that it will send all your data. While it might always work in your development environment, that's the kind of assumption that will bite you later.



For data input (lo_server), you said that the incomplete message could be stored while we wait on lo_wait. If this is correct, I can try to implement something.  Right now, I have no idea of how this could be implemented for message sending.

I think it is important to fix these problems so TCP support will be complete.


Best,
Cam




On 10 avr. 2012, at 10:41, Camille Troillard wrote:

> On 9 avr. 2012, at 22:25, Stephen Sinclair wrote:
> 
>>> I think a proper solution would be to maintain the state read_size and bytesRead at the level of the lo_server (like a small state machine) and adequately read the message with the available data, or wait for more data.  If not all the data has been read, then we wait again for more data, and continue the reading were it was left.
>>> 
>>> Stephen, what do you think of this solution?  I think this would pose a semantic problem with lo_wait and lo_server_read because in fact you don't read a message as it fails in the middle of reading it.
>> 
>> I see what you mean, it would violate the idea that after lo_wait()
>> there should be a full message read before returning.
> 
> Yes, in fact I was thinking about a previous discussion where you said that semantically lo_server_recv was supposed to return something, but that's the same idea.
> 
> 
>> That's actually
>> quite tough, I will have to play with it a little to see if there is a
>> solution.  Just acknowledging your bug report for now.
> 
> Thank you.
> I can live with the temporary fix I have implemented.
> 
> 
>> I wonder if it means this semantic aspect of lo_server_recv() is not feasible in the
>> general case.
> 
> If you think about the semantics of the recv call, it does not guarantee you that you will receive exactly the amount of bytes you requested (hence our discussion!), so it wouldn't shock me that lo_server_recv behaves the same as recv but at the application level, i.e. you are not guaranteed to receive the exact number of OSC messages you expected (one message for instance).
> 
> 
>> Unless lo_wait() actually reads the message and queues
>> it up, leaving lo_server_recv() to perform dispatching.. maybe that's
>> not a terrible idea?
> 
> Sounds like a nice idea.
> 
> What about queuing the received bytes instead of queuing the message, or maybe that's what you meant?  Just keep in mind that even the byte count prefix could be truncated, which means that you don't even have a message at this level.  In the end what is important is to make sure you have read 4 bytes for the size, then N bytes to decode the complete OSC message.

To quote George R. R. Martin's acknowledgements in A Feast for Crows:

"This one was a bitch."

But it works!  Or seems to at least.  It took me 3 goes at it before I
understood what was missing.  It's going to need a lot more testing
than I have given it so far, particularly with multiple connections.
Getting bidirectional TCP was tricky because the required information
for sending replies was discarded early in the connection process.  I
had to add an array of lo_address structures to the server to save the
"sources" of each connection after accept()ing them.

Also, on sending a reply, it was necessary to add the sending socket
to the "from" server's socket list.  I ended up having to modify the
call signature for dispatch_data() and dispatch_method() just to pass
the socket information through to the method handler so that the
correct source could be determined.

So this patch increased yet again some of the cross-talk between
modules, unfortunately exposing some internal functions to the ABI.
(I like to keep internal functions static if possible, hate moving
them to lo_internal.h)

Anyways, as always, please test.  Hopefully with this feature out of
the way I can move on to fixing remaining bugs and get a release out
the door.

Steve