liblo-devel Mailing List for LibLO

> Interesting, we have considered the converse, adding a JACK transport
> for connections that require high bandwidth ;)  Not quite there yet
> though, everything is still UDP/IP packets for now.  However each
> connection can have its own "properties", so in theory it's possible
> to specify other transport layers.  We're planning to add an option
> for TCP soon, so liblo's TCP support will get a lot more exercise from
> me eventually.
>

My use of Control Voltages over JACK in Non-Mixer and Non-DAW sparked a
rather lengthy discussion (during my hiatus) on the LAD list about adding
some kind of 'control' port type to JACK. This would be very nice indeed.
Unfortunately the thread derailed as usual and nothing ever came of it.
Most of the commentors seemed to miss my original point. All I wanted was
arbitrary port types in the JACK API so that I could have, for instance,
sample rate control data (Control Voltage) and timestamped control data
type ports (without JACK having to know anything about how they work) and
any connection manager could connect and disconnect them without the user
accidentally plugging one type into the other. Honestly, I would have
preferred such a solution to using OSC simply for the possibility of a
unified connection graph, although, that being said, there's no reason why
something like Patchage couldn't be taught how to manage libmapper type OSC
signals too.


>
> > I think the only things I'm lacking are the formula, and I don't think
> that
> > should go in the system anyway, as you could always have a device sit
> > between two peers and do transformations.
>
> Yup, we do that for more complex things that require "mixing" signals.
> If two clients send to the same destination, the messages will just
> mix together, so if it's necessary to add two signals or combine them
> in other ways, it's necessary to create an intermediate layer.  We are
> doing this for some fun machine learning stuff.
>
>
I saw the video ;-)


> > If it weren't for the multicast stuff and the lack of an obvious way to
> > assign specific peer names by a central authority, I would have probably
> > just used libmapper... It certainly would have been less trouble, I'm
> sure.
>
> Multicast is only used in libmapper for coordinating, the data streams
> are sent directly between peers.  We chose multicast because it was a
> convenient way to get multiple computers to find each other.  Actually
> I've had some ideas about allowing peers to mirror the multicast bus
> to each other, allowing a kind of mesh network approach. We were
> specifically looking to avoid the "central authority" approach
> however, but there's no fundamental reason we couldn't have gone that
> way.  We just used multicast because it meant not having to run a
> "server".
>
> For the session management scenario I can totally see why having a
> "master control station" makes sense though, as it simplifies certain
> things.  (Hence *cough* some of our difficulty with er.. session
> management. We've got some good ideas though, just more ideas than
> time to work on them.)
>

I definitely understand where the multicast is useful in libmappers
'device' model, but I'm working with pure software, and 99.99% of the time
that software is all running on the same host. So in my environment it is
at best unnecessary and at worst confusing/troublesome.

The bigger problem is the one of naming. In order for session management to
work, peer names need to be both unique AND reliably recreatable, which is
why I have NSM assign them. NSM gives each client its
unique-per-instance-per-session ID, and allows clients to broadcast
messages announcing their presence on a bus. The rest of the communication
is peer to peer. An ad-hoc system of name assignment is no good, because it
becomes impossible to reliably persist the connection graph  across
sessions. This is a problem with JACK too, which appends an ordinal number
to non-unique client names, so applications supporting NSM have to use the
client ID provided by the NSM server as their client name when registering
with JACK.

Now that I think about it, the possibility of adding 'devices' to a session
intrigues me. I've already got plans to use my signal framework to make an
NSM aware bidirectional MIDI<->Control Signal interface to finally make my
BCF2000 device useful again. So, in a way, this would be a 'device'
participating in the session (even though it wouldn't be over a network).

A function to compare lo_addresses is not necessarily a bad idea,
> since it seems to me that comparing IP addresses would require some
> kind of custom function anyways, due to handling IPv6.  Suddenly you
> require some smarts to check if two addresses are the same instead of
> being able to just compare some integers. (For instance, an IPv4
> address can be embedded in an IPv6 address...)
>
> You could restrict your application to IPv4 though, to simplify, and I
> agree there should be a way to get at this information.  The
> lo_address structure keeps an addrinfo anyways, all it needs is an
> accessor function.
>

I'd be happy with just the accessor.


> > You're right. My fault. Let me say it another way: I don't see why
> lo_send()
> > should be in the API ;-)
>
> Maybe I'm not understanding.. sometimes apps do not need to receive
> OSC messages but only send them, I've definitely written programs that
> never create a lo_server().
>

Ahh. I see. It never occurred to me that one would do that. My worry is
that people will call lo_send() by mistake even they already have a
lo_server.

> I'm not really talking about lo_server_thread (I don't use it either).
> Just
> > about what is threadsafe and what isn't.
>
> Right.  This might take some thought and some work.
>
> Let's see: There is very little global data shared between calls to
> liblo fortunately, so most of it should be threadsafe between
> different lo_address and lo_server instances.  I would probably avoid
> passing in the same instance of these in different threads
> simultaneously, though most _get() functions are likely safe to call
> in parallel, but this would need verifying.
>
> One issue that has always irked me on this front is the use of the
> lo_client_sockets global data in server.c/send.c. It is used for
> reusing sockets between calls to lo_send(), and for reusing the first
> server socket if one has been previously created. I recall looking
> into removing it once, or at least ensure that it only gets written to
> once, but never finished the job.  I think it turned out to be more
> complicated than I'd expected. Not sure if this poses issues with
> thread safety but it struck me as one of the few places where the use
> of global data might cause problems.
>
>
I don't use lo_send, so I think I'm OK. I'm pleased to say that the (heavy)
use of liblo (0.26) has not yet caused any crashes for me.

On 28 févr. 2012, at 23:17, Stephen Sinclair wrote:

> Just a quick response to bring up some points I wanted to talk about
> on the list with regards to TCP..
> 
> On Tue, Feb 28, 2012 at 5:01 PM, Camille Troillard
> <ca...@os...> wrote:
>> The client code is a TCP client written in Cocoa with the VVOSC
>> library, but only the encoding functions are used.  The networking
>> code is handled by a NSSocket, which is basically a wrapper around
>> unix sockets.  I understand that using liblo would not cause this
>> problem to happen, but here the code is used in another developer's
>> application, which makes me believe the problem is legitimate.
> 
> I agree that it's absolutely legitimate.  One of my main concerns with
> the TCP support is that there is no agreed-on standard for how a TCP
> transport for OSC should work.  There isn't even an agreement on how
> packetization should happen, let alone small connection issues like
> this.
> 
> In the last few years CNMAT have been proposing that SLIP should be
> used on the TCP transport.  But if I did that, then for instance it
> would probably break your application that wants to talk to VVOSC.

The application is not yet released and I can talk with the developer to delay the support for TCP until the case is resolved (and in OSCulator too), but considering how fast OSC is evolving I fear it may take some time.  On the other hand, I saw that there was some progress on the osc-devel list and that the final OSC 1.1 spec should be released soon, but how soon? ...


> SLIP seems unnecessary to me for TCP, although it's useful for serial
> line transports since it is easy to handle the case where a stream
> starts mid-message.  However they are interested in standardizing SLIP
> for any stream-based tranport, which includes TCP.  I'm willing to go
> with it but it's another instance where this change would break
> compatibility with other TCP implementations.

Stephen, I totally agree with you that the SLIP encoding is unnecessary.  And other developers have argued in the past against the SLIP encoding approach on osc-devel (for example, an email from an engineer at Meyer Sound back in 2009, http://lists.create.ucsb.edu/pipermail/osc_dev/2009-August/001735.html).


> Frankly I'm not 100% sure whether converting to SLIP is more trouble
> than it's worth, but the fact is that there needs to be some agreement
> between OSC implementations on how TCP should work.  Lately I've
> downloaded every open source OSC implementation I can get my hands on
> and I plan to go through them and figure out how each one has handled
> TCP, to see what is most common.  If it turns out that everyone uses
> the length-prefix approach, it may not be worth it to switch to SLIP,
> but this means going against the one group that seems to have any
> chance of standardizing it.
> 
> tl;dr: I want liblo's TCP to work well with other implementations, but
> I also want to consider the OSC 1.1 "standard" that has been proposed
> in 2009.  What to do.. what to do..

What about discussing with Andy Schmeder about this issue?
Maybe there is a chance to convince them to adopt the simpler approach?


Cam

On Mon, Feb 27, 2012 at 6:59 PM, J. Liles <mal...@gm...> wrote:
>
> Ha. Yes, I saw that recently. I wasn't aware you were the one working on it.
> I actually took a couple of days to implement something similar for Non
> (going into the next release). The difference is that I don't use multicast
> (peers discover eachother through NSM), and a central authority (NSM)
> assigns the symbolic names for each peer. Therefore, all the connections are
> internal to the session. I have outputs, inputs, listing, automatic syncing
> with notifications of signal ports being destroyed and created, renamed etc.
> All signals have range limits and one output can connect to multiple inputs
> and inputs receiving signal data from multiple outputs do additive mixing.
> So, basically, I'm emulating the exact features I had with Control Voltage
> signals over JACK, but in a lower data rate with OSC and calling it Control
> Signals.

Interesting, we have considered the converse, adding a JACK transport
for connections that require high bandwidth ;)  Not quite there yet
though, everything is still UDP/IP packets for now.  However each
connection can have its own "properties", so in theory it's possible
to specify other transport layers.  We're planning to add an option
for TCP soon, so liblo's TCP support will get a lot more exercise from
me eventually.

> I think the only things I'm lacking are the formula, and I don't think that
> should go in the system anyway, as you could always have a device sit
> between two peers and do transformations.

Yup, we do that for more complex things that require "mixing" signals.
If two clients send to the same destination, the messages will just
mix together, so if it's necessary to add two signals or combine them
in other ways, it's necessary to create an intermediate layer.  We are
doing this for some fun machine learning stuff.

> If it weren't for the multicast stuff and the lack of an obvious way to
> assign specific peer names by a central authority, I would have probably
> just used libmapper... It certainly would have been less trouble, I'm sure.

Multicast is only used in libmapper for coordinating, the data streams
are sent directly between peers.  We chose multicast because it was a
convenient way to get multiple computers to find each other.  Actually
I've had some ideas about allowing peers to mirror the multicast bus
to each other, allowing a kind of mesh network approach. We were
specifically looking to avoid the "central authority" approach
however, but there's no fundamental reason we couldn't have gone that
way.  We just used multicast because it meant not having to run a
"server".

For the session management scenario I can totally see why having a
"master control station" makes sense though, as it simplifies certain
things.  (Hence *cough* some of our difficulty with er.. session
management. We've got some good ideas though, just more ideas than
time to work on them.)

> Anyway, you'll be able to see what I've done in the next release of Non*.
> Maybe we can find some ways to bring the two systems together in a
> compatible way. IMHO, OSC is practically useless for audio software control
> purposes without some kind of signal layer like libmapper provides, so I'm
> all for helping its adoption, even if I do seem a little Gung Ho by
> implementing my own.

Sure, let's see where it goes.  We'd love more people to use it and
think we've got a good approach here, but it's just as interesting to
hear about places where it sort-of-fits-but-not-exactly, because maybe
it could use ideas we didn't think of.  Some sort of connection
protocol for OSC is clearly needed, it's just hard to get people to
agree on one.

> It's just usually faster for me to do it myself than
> deal with external dependencies.

Believe me I get that ;)


> Just adding + getpid() in the equation would probably fix it. However, I
> think one of the patches I saw relied on the OS to assign the port number,
> which is probably even better.

Agreed, I'll look into it.

>
>>
>> > 2. Bi-directional TCP is lacking, and it would be nice to have.
>>
>> Main problem here is API.  I'm not sure how it should be done in terms
>> of how specific the relationship between a server and address.  There
>> were some tentative ideas on the list previously but nothing concrete.
>>  Something about lo_address_new_for_server() or something to that
>> effect, or maybe lo_server_get_address().. hm. Or maybe
>> lo_send_message_from() would be enough to do this.
>
>
> I don't see what lo_send_from couldn't.

Maybe that's the way to go then.

>> > 3. There's no call that I can see in the API to (always) get an IP
>> > address out of a lo_address handle.
>>
>> There is lo_address_get_hostname() which returns a string that could
>> be passed into gethostbyname().  It could be nice to add a function
>> that returns the already-resolved address, although it would have to
>> smoothly handle both IPv4 and IPv6.
>
>
> Specifically, my issue has to do with storing peer addresses in tables and
> comparing them with incoming messages. Even just an API function to compare
> two lo_addresses would be fine, but I think getting the IP is more general
> (and yes I know I'm ignoring NAT and all that stuff).

A function to compare lo_addresses is not necessarily a bad idea,
since it seems to me that comparing IP addresses would require some
kind of custom function anyways, due to handling IPv6.  Suddenly you
require some smarts to check if two addresses are the same instead of
being able to just compare some integers. (For instance, an IPv4
address can be embedded in an IPv6 address...)

You could restrict your application to IPv4 though, to simplify, and I
agree there should be a way to get at this information.  The
lo_address structure keeps an addrinfo anyways, all it needs is an
accessor function.

>> 4. I'm not sure that I understand why lo_send can't always behave like
>> lo_send_from.
>
>> I'm not sure what you mean here, lo_send() doesn't take the same
>> arguments as lo_send_from()?  The idea is to be able to send a message
>> that is not associated with a server.
>
>
> You're right. My fault. Let me say it another way: I don't see why lo_send()
> should be in the API ;-)

Maybe I'm not understanding.. sometimes apps do not need to receive
OSC messages but only send them, I've definitely written programs that
never create a lo_server().

>> > 5. Multithreading semantics aren't articulated in the documentation.
>> > Is it save to call lo_send_from on the same server that's being recv'd
>> > on in another thread?
>>
>> Documentation could be improved.  Personally I'm not a fan of using
>> any threading with liblo, I try to keep my liblo calls on the same
>> thread, so I never use the lo_server_thread API.
>> As for the specific question, lo_send_from() only accesses the
>> server's fd, which doesn't change so I can't think of any threading
>> issues here.
>
>
> I'm not really talking about lo_server_thread (I don't use it either). Just
> about what is threadsafe and what isn't.

Right.  This might take some thought and some work.

Let's see: There is very little global data shared between calls to
liblo fortunately, so most of it should be threadsafe between
different lo_address and lo_server instances.  I would probably avoid
passing in the same instance of these in different threads
simultaneously, though most _get() functions are likely safe to call
in parallel, but this would need verifying.

One issue that has always irked me on this front is the use of the
lo_client_sockets global data in server.c/send.c. It is used for
reusing sockets between calls to lo_send(), and for reusing the first
server socket if one has been previously created. I recall looking
into removing it once, or at least ensure that it only gets written to
once, but never finished the job.  I think it turned out to be more
complicated than I'd expected. Not sure if this poses issues with
thread safety but it struck me as one of the few places where the use
of global data might cause problems.

Steve

Just a quick response to bring up some points I wanted to talk about
on the list with regards to TCP..

On Tue, Feb 28, 2012 at 5:01 PM, Camille Troillard
<ca...@os...> wrote:
> The client code is a TCP client written in Cocoa with the VVOSC
> library, but only the encoding functions are used.  The networking
> code is handled by a NSSocket, which is basically a wrapper around
> unix sockets.  I understand that using liblo would not cause this
> problem to happen, but here the code is used in another developer's
> application, which makes me believe the problem is legitimate.

I agree that it's absolutely legitimate.  One of my main concerns with
the TCP support is that there is no agreed-on standard for how a TCP
transport for OSC should work.  There isn't even an agreement on how
packetization should happen, let alone small connection issues like
this.

In the last few years CNMAT have been proposing that SLIP should be
used on the TCP transport.  But if I did that, then for instance it
would probably break your application that wants to talk to VVOSC.

SLIP seems unnecessary to me for TCP, although it's useful for serial
line transports since it is easy to handle the case where a stream
starts mid-message.  However they are interested in standardizing SLIP
for any stream-based tranport, which includes TCP.  I'm willing to go
with it but it's another instance where this change would break
compatibility with other TCP implementations.

Frankly I'm not 100% sure whether converting to SLIP is more trouble
than it's worth, but the fact is that there needs to be some agreement
between OSC implementations on how TCP should work.  Lately I've
downloaded every open source OSC implementation I can get my hands on
and I plan to go through them and figure out how each one has handled
TCP, to see what is most common.  If it turns out that everyone uses
the length-prefix approach, it may not be worth it to switch to SLIP,
but this means going against the one group that seems to have any
chance of standardizing it.

tl;dr: I want liblo's TCP to work well with other implementations, but
I also want to consider the OSC 1.1 "standard" that has been proposed
in 2009.  What to do.. what to do..

Steve

On 28 févr. 2012, at 22:39, Stephen Sinclair wrote:

>> lo_server_recv blocks when a connection is made from a client to the server because the server tries to read data just after the socket is accepted, even though there is no data to read yet. After the client send its first message to the server everything comes back to normal.
> 
> Thanks for that information, that's definitely more descriptive of the
> problem.  So there's certainly some broken semantics there, I would
> not expect lo_server_recv() to block after lo_server_wait(), and
> lo_server_recv_noblock() should certainly never block.

Yes.


> I'll try writing a test for these conditions and go from there.
> Certainly your patch is problematic unfortunately, because it sort of
> creates an opposite problem where lo_server_recv() can return without
> blocking, which is against the expectations of some user code.
> Generally lo_server_recv() should always return a message if one is
> available, but with your patch it returns without reading it.

Ahhh right, I overlooked that.


> That's why I made it call back to select() again to check if there is data to
> read before forcing a read() call.  I'm surprised that it still blocks
> for you in that case -- the two possible conditions, as far as I can
> see are:
> 
> * client makes a connection, no data
> -> server accepts connection, select() says there is no data

On Mac OS X, poll is used and blocks until data is present (server.c, line 695).  If however I force the use of select, the application hangs on select (server.c, line 726).


> * cilent makes a connection, sends data
> -> server accepts connection, select() says there is data, call read()
> 
> What is happening in your program that is not one of these two cases?
> Somehow read() is getting called when there is no data, even though
> read() is only called after select() says there is data, so there must
> be some very subtle thing going on here.

This time read is not called, which is fine.


> Question: what does your client code look like? The only thing I still
> find confusing is that you say, "the server tries to read data just
> after the socket is accepted, even though there is no data to read
> yet."  However, afaik there is no way for liblo client to make a
> connection to a server without sending a message, so there should
> always be a packet of data to read after accept().  Maybe another OSC
> clients may behave differently though..

The client code is a TCP client written in Cocoa with the VVOSC library, but only the encoding functions are used.  The networking code is handled by a NSSocket, which is basically a wrapper around unix sockets.  I understand that using liblo would not cause this problem to happen, but here the code is used in another developer's application, which makes me believe the problem is legitimate.


Cam

On Tue, Feb 28, 2012 at 4:16 PM, Camille Troillard
<ca...@os...> wrote:
> Stephen,
>
>
> On 28 févr. 2012, at 21:45, Stephen Sinclair <rad...@gm...> wrote:
>
>> I see, I'll have to do some testing on OS X. The reason your patch
>> breaks testlo is that it breaks the semantics of lo_server_recv():
>>
>> "Block, waiting for an OSC message to be received.
>>
>> The return value is the number of bytes in the received message. The
>> message will be dispatched to a matching method if one is found."
>
> Alright, fair enough!
>
>
>> In other words it's supposed to block the program until data is
>> received, as you have observed.  Is this not the behaviour you
>> expected?  If you don't want blocking, there is,
>> lo_server_recv_noblock(), exactly for that.
>
> Yes, I was aware of this, but this is not the problem I am outlining (see below).
>
>
>> Actually I think you didn't mention the context in which
>> lo_server_recv_raw_stream() is getting called, are you using
>> lo_server_recv() or lo_server_recv_noblock()?  If _noblock() is
>> blocking, then that is certainly a problem. Perhaps recv_raw_stream
>> needs a flag to know it is being called from _noblock().
>
> I use lo_server_wait in a thread to notify when the server socket is ready. In the main thread, I call lo_server_recv when the call to lo_server_wait has succeeded.
>
> This allows me to integrate a liblo server within a Cocoa run loop without having to deal with complex multithreading issues.
>
> Using lo_server_recv_noblock duplicates the calls to lo_server_wait and therefore in my case would not change anything: when I use lo_server_recv_noblock, the program blocks anyway.
>
> lo_server_recv blocks when a connection is made from a client to the server because the server tries to read data just after the socket is accepted, even though there is no data to read yet. After the client send its first message to the server everything comes back to normal.

Thanks for that information, that's definitely more descriptive of the
problem.  So there's certainly some broken semantics there, I would
not expect lo_server_recv() to block after lo_server_wait(), and
lo_server_recv_noblock() should certainly never block.

I'll try writing a test for these conditions and go from there.
Certainly your patch is problematic unfortunately, because it sort of
creates an opposite problem where lo_server_recv() can return without
blocking, which is against the expectations of some user code.
Generally lo_server_recv() should always return a message if one is
available, but with your patch it returns without reading it.  That's
why I made it call back to select() again to check if there is data to
read before forcing a read() call.  I'm surprised that it still blocks
for you in that case -- the two possible conditions, as far as I can
see are:

* client makes a connection, no data
 -> server accepts connection, select() says there is no data

* cilent makes a connection, sends data
 -> server accepts connection, select() says there is data, call read()

What is happening in your program that is not one of these two cases?
Somehow read() is getting called when there is no data, even though
read() is only called after select() says there is data, so there must
be some very subtle thing going on here.

Question: what does your client code look like? The only thing I still
find confusing is that you say, "the server tries to read data just
after the socket is accepted, even though there is no data to read
yet."  However, afaik there is no way for liblo client to make a
connection to a server without sending a message, so there should
always be a packet of data to read after accept().  Maybe another OSC
clients may behave differently though..

Steve

Stephen,


On 28 févr. 2012, at 21:45, Stephen Sinclair <rad...@gm...> wrote:

> I see, I'll have to do some testing on OS X. The reason your patch
> breaks testlo is that it breaks the semantics of lo_server_recv():
> 
> "Block, waiting for an OSC message to be received.
> 
> The return value is the number of bytes in the received message. The
> message will be dispatched to a matching method if one is found."

Alright, fair enough!


> In other words it's supposed to block the program until data is
> received, as you have observed.  Is this not the behaviour you
> expected?  If you don't want blocking, there is,
> lo_server_recv_noblock(), exactly for that.

Yes, I was aware of this, but this is not the problem I am outlining (see below).


> Actually I think you didn't mention the context in which
> lo_server_recv_raw_stream() is getting called, are you using
> lo_server_recv() or lo_server_recv_noblock()?  If _noblock() is
> blocking, then that is certainly a problem. Perhaps recv_raw_stream
> needs a flag to know it is being called from _noblock().

I use lo_server_wait in a thread to notify when the server socket is ready. In the main thread, I call lo_server_recv when the call to lo_server_wait has succeeded.

This allows me to integrate a liblo server within a Cocoa run loop without having to deal with complex multithreading issues.

Using lo_server_recv_noblock duplicates the calls to lo_server_wait and therefore in my case would not change anything: when I use lo_server_recv_noblock, the program blocks anyway. 

lo_server_recv blocks when a connection is made from a client to the server because the server tries to read data just after the socket is accepted, even though there is no data to read yet. After the client send its first message to the server everything comes back to normal. 


All the best,
Cam

On Tue, Feb 28, 2012 at 1:58 PM, Camille Troillard
<ca...@os...> wrote:
> I should add that commenting the line with "goto again;" makes the application behave as expected.  Though maybe I have not understood properly the reason why you want to call poll/select again...
>
>
> On 28 févr. 2012, at 19:56, Camille Troillard wrote:
>
>> Hey Stephen,
>>
>> On 28 févr. 2012, at 18:04, Stephen Sinclair wrote:
>>
>>> Seems it was due to the hacky "repeat" flag in that loop.  It was
>>> there to stop from continuing to loop over the socket list after the
>>> list has been modified, but really it should have re-called
>>> select/poll instead.  Can you test this modified patch?  It seems to
>>> fix testlo for me.
>>>
>>> Another approach might be to save the new socket temporarily, finish
>>> looping over the select() results, and _then_ modify the socket list,
>>> but I'm not sure that kind of complexity is necessary. Calling
>>> select/poll a second time can't hurt, can it?
>>
>> It seems the patch does not do exactly what I was suggesting.
>>
>> On OS X, the loop now hangs on poll(s->sockets, s->sockets_len, -1) after a socket has been accepted.  I believe that lo_server_recv_raw_stream should return right after a socket has been accepted, thus giving back control to the caller, that is not goto the again label.

I see, I'll have to do some testing on OS X. The reason your patch
breaks testlo is that it breaks the semantics of lo_server_recv():

"Block, waiting for an OSC message to be received.

The return value is the number of bytes in the received message. The
message will be dispatched to a matching method if one is found."

In other words it's supposed to block the program until data is
received, as you have observed.  Is this not the behaviour you
expected?  If you don't want blocking, there is,
lo_server_recv_noblock(), exactly for that.

Actually I think you didn't mention the context in which
lo_server_recv_raw_stream() is getting called, are you using
lo_server_recv() or lo_server_recv_noblock()?  If _noblock() is
blocking, then that is certainly a problem. Perhaps recv_raw_stream
needs a flag to know it is being called from _noblock().

Steve

I should add that commenting the line with "goto again;" makes the application behave as expected.  Though maybe I have not understood properly the reason why you want to call poll/select again...


On 28 févr. 2012, at 19:56, Camille Troillard wrote:

> Hey Stephen,
> 
> On 28 févr. 2012, at 18:04, Stephen Sinclair wrote:
> 
>> Seems it was due to the hacky "repeat" flag in that loop.  It was
>> there to stop from continuing to loop over the socket list after the
>> list has been modified, but really it should have re-called
>> select/poll instead.  Can you test this modified patch?  It seems to
>> fix testlo for me.
>> 
>> Another approach might be to save the new socket temporarily, finish
>> looping over the select() results, and _then_ modify the socket list,
>> but I'm not sure that kind of complexity is necessary. Calling
>> select/poll a second time can't hurt, can it?
> 
> It seems the patch does not do exactly what I was suggesting.
> 
> On OS X, the loop now hangs on poll(s->sockets, s->sockets_len, -1) after a socket has been accepted.  I believe that lo_server_recv_raw_stream should return right after a socket has been accepted, thus giving back control to the caller, that is not goto the again label.
> 
> 
> Best,
> Cam

Hey Stephen,


On 28 févr. 2012, at 18:04, Stephen Sinclair wrote:

> Seems it was due to the hacky "repeat" flag in that loop.  It was
> there to stop from continuing to loop over the socket list after the
> list has been modified, but really it should have re-called
> select/poll instead.  Can you test this modified patch?  It seems to
> fix testlo for me.
> 
> Another approach might be to save the new socket temporarily, finish
> looping over the select() results, and _then_ modify the socket list,
> but I'm not sure that kind of complexity is necessary. Calling
> select/poll a second time can't hurt, can it?

It seems the patch does not do exactly what I was suggesting.

On OS X, the loop now hangs on poll(s->sockets, s->sockets_len, -1) after a socket has been accepted.  I believe that lo_server_recv_raw_stream should return right after a socket has been accepted, thus giving back control to the caller, that is not goto the again label.


Best,
Cam

Hello Stephen,


On 28 févr. 2012, at 17:09, Stephen Sinclair wrote:

> Finally got around to it.  Yes, I believe you're right.. when the
> listening socket signals an event, it only means it's ready to accept
> a connection, not that it is ready to be read().  I've applied your
> patch privately, I'll commit it soon.

Thank you.


> Just a clarification, when you say your application "hangs", do you
> mean it pauses temporarily or that it actually stalls permanently?
> Just wondering because I can see the reason for a pause, but can't see
> why it would cause permanent damage -- lo_send() always sends data
> along with the connection request afaik.

The application (or server loop) stalls permanently until a packet is received, ie, the client sends the first OSC packet after the connection is made.


> Also, in reading up a bit I see that there is the potential for a race
> condition between select()/poll() and accept(), which requires the
> listening socket be set non-blocking.  (Which _would_ lead to a
> permanent hang.)  I'll fix this now that I see it.  Great that someone
> other than me is testing the TCP implementation! :)

Yay for  TCP!


Cam

Seems it was due to the hacky "repeat" flag in that loop.  It was
there to stop from continuing to loop over the socket list after the
list has been modified, but really it should have re-called
select/poll instead.  Can you test this modified patch?  It seems to
fix testlo for me.

Another approach might be to save the new socket temporarily, finish
looping over the select() results, and _then_ modify the socket list,
but I'm not sure that kind of complexity is necessary. Calling
select/poll a second time can't hurt, can it?

Steve

On Tue, Feb 28, 2012 at 11:18 AM, Stephen Sinclair <rad...@gm...> wrote:
> Hm on second thought the patch seems to cause testlo to fail on a TCP
> test.  Will try to look into it today..
>
> Steve
>
> On Tue, Feb 28, 2012 at 11:09 AM, Stephen Sinclair <rad...@gm...> wrote:
>> Camille,
>>
>> Finally got around to it.  Yes, I believe you're right.. when the
>> listening socket signals an event, it only means it's ready to accept
>> a connection, not that it is ready to be read().  I've applied your
>> patch privately, I'll commit it soon.
>>
>> Just a clarification, when you say your application "hangs", do you
>> mean it pauses temporarily or that it actually stalls permanently?
>> Just wondering because I can see the reason for a pause, but can't see
>> why it would cause permanent damage -- lo_send() always sends data
>> along with the connection request afaik.
>>
>> Also, in reading up a bit I see that there is the potential for a race
>> condition between select()/poll() and accept(), which requires the
>> listening socket be set non-blocking.  (Which _would_ lead to a
>> permanent hang.)  I'll fix this now that I see it.  Great that someone
>> other than me is testing the TCP implementation! :)
>>
>> Steve
>>
>>
>> On Fri, Feb 17, 2012 at 3:52 AM, Camille Troillard
>> <ca...@os...> wrote:
>>> Hi,
>>>
>>> When a liblo server is configured with a TCP socket, it manages one listening socket and a list of streaming sockets.  The code to read from TCP sockets is in server.c, in lo_server_recv_raw_stream, line 665.  In this function, is an event happened on the listening socket, we call the function accept, and then if everything went fine, proceed to reading the first packet.
>>>
>>> There is a problem that causes my application to hang while waiting for the first packet of data, just after a connection has been accepted.  In fact, once a socket is accepted, liblo should not try to read from it, but instead give up control to the application.
>>>
>>> Attached is a patch that attempts to fix that.  I hope I got the logic right.
>>>
>>>
>>> Best,
>>> Cam
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Virtualization & Cloud Management Using Capacity Planning
>>> Cloud computing makes use of virtualization - but cloud computing
>>> also focuses on allowing computing to be delivered as a service.
>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>>> _______________________________________________
>>> liblo-devel mailing list
>>> lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>>

Hm on second thought the patch seems to cause testlo to fail on a TCP
test.  Will try to look into it today..

Steve

On Tue, Feb 28, 2012 at 11:09 AM, Stephen Sinclair <rad...@gm...> wrote:
> Camille,
>
> Finally got around to it.  Yes, I believe you're right.. when the
> listening socket signals an event, it only means it's ready to accept
> a connection, not that it is ready to be read().  I've applied your
> patch privately, I'll commit it soon.
>
> Just a clarification, when you say your application "hangs", do you
> mean it pauses temporarily or that it actually stalls permanently?
> Just wondering because I can see the reason for a pause, but can't see
> why it would cause permanent damage -- lo_send() always sends data
> along with the connection request afaik.
>
> Also, in reading up a bit I see that there is the potential for a race
> condition between select()/poll() and accept(), which requires the
> listening socket be set non-blocking.  (Which _would_ lead to a
> permanent hang.)  I'll fix this now that I see it.  Great that someone
> other than me is testing the TCP implementation! :)
>
> Steve
>
>
> On Fri, Feb 17, 2012 at 3:52 AM, Camille Troillard
> <ca...@os...> wrote:
>> Hi,
>>
>> When a liblo server is configured with a TCP socket, it manages one listening socket and a list of streaming sockets.  The code to read from TCP sockets is in server.c, in lo_server_recv_raw_stream, line 665.  In this function, is an event happened on the listening socket, we call the function accept, and then if everything went fine, proceed to reading the first packet.
>>
>> There is a problem that causes my application to hang while waiting for the first packet of data, just after a connection has been accepted.  In fact, once a socket is accepted, liblo should not try to read from it, but instead give up control to the application.
>>
>> Attached is a patch that attempts to fix that.  I hope I got the logic right.
>>
>>
>> Best,
>> Cam
>>
>>
>> ------------------------------------------------------------------------------
>> Virtualization & Cloud Management Using Capacity Planning
>> Cloud computing makes use of virtualization - but cloud computing
>> also focuses on allowing computing to be delivered as a service.
>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>

Camille,

Finally got around to it.  Yes, I believe you're right.. when the
listening socket signals an event, it only means it's ready to accept
a connection, not that it is ready to be read().  I've applied your
patch privately, I'll commit it soon.

Just a clarification, when you say your application "hangs", do you
mean it pauses temporarily or that it actually stalls permanently?
Just wondering because I can see the reason for a pause, but can't see
why it would cause permanent damage -- lo_send() always sends data
along with the connection request afaik.

Also, in reading up a bit I see that there is the potential for a race
condition between select()/poll() and accept(), which requires the
listening socket be set non-blocking.  (Which _would_ lead to a
permanent hang.)  I'll fix this now that I see it.  Great that someone
other than me is testing the TCP implementation! :)

Steve


On Fri, Feb 17, 2012 at 3:52 AM, Camille Troillard
<ca...@os...> wrote:
> Hi,
>
> When a liblo server is configured with a TCP socket, it manages one listening socket and a list of streaming sockets.  The code to read from TCP sockets is in server.c, in lo_server_recv_raw_stream, line 665.  In this function, is an event happened on the listening socket, we call the function accept, and then if everything went fine, proceed to reading the first packet.
>
> There is a problem that causes my application to hang while waiting for the first packet of data, just after a connection has been accepted.  In fact, once a socket is accepted, liblo should not try to read from it, but instead give up control to the application.
>
> Attached is a patch that attempts to fix that.  I hope I got the logic right.
>
>
> Best,
> Cam
>
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

On Mon, Feb 27, 2012 at 3:38 PM, Stephen Sinclair <rad...@gm...>wrote:

> Hi J.,
>
> Nice feedback and great-looking project.  It actually reminds me a
> little of what we're working in my lab, although the goals are
> different, I wonder if there might be some common ground.
>
> Our "big project" with liblo right now is libmapper, a library for
> managing "mapping connections" between programs.  This is a little
> different than session management -- in fact managing restoration of
> state is a current issue for us, so it's nice to see ideas like you
> show in that video, maybe we could use something like that.
>
> Basically libmapper is about having multiple processes that can send
> OSC messages to each other, however instead of each process having to
> know what kinds of messages are valid for one other, the idea is that
> each process announces on a multicast bus what messages they support
> for input and output.  Then we use a GUI to instruct one device to
> start sending messages to another, with some optional transformation
> of the data.  So the devices never actually send their output message,
> instead they transform it to the format required by the destination.
> It's all decentralized and works across networks.  The idea is to
> build up a bit of an ecosystem of libmapper programs for different
> kinds of input devices and audio software, so that any device can be
> mapped to any synthesizer.
>
> Anyways, could be interesting for you, dunno. If you want more info,
> check http://libmapper.org
>

Ha. Yes, I saw that recently. I wasn't aware you were the one working on
it. I actually took a couple of days to implement something similar for Non
(going into the next release). The difference is that I don't use multicast
(peers discover eachother through NSM), and a central authority (NSM)
assigns the symbolic names for each peer. Therefore, all the connections
are internal to the session. I have outputs, inputs, listing, automatic
syncing with notifications of signal ports being destroyed and created,
renamed etc. All signals have range limits and one output can connect to
multiple inputs and inputs receiving signal data from multiple outputs do
additive mixing. So, basically, I'm emulating the exact features I had with
Control Voltage signals over JACK, but in a lower data rate with OSC and
calling it Control Signals.

I think the only things I'm lacking are the formula, and I don't think that
should go in the system anyway, as you could always have a device sit
between two peers and do transformations.

If it weren't for the multicast stuff and the lack of an obvious way to
assign specific peer names by a central authority, I would have probably
just used libmapper... It certainly would have been less trouble, I'm sure.

Anyway, you'll be able to see what I've done in the next release of Non*.
Maybe we can find some ways to bring the two systems together in a
compatible way. IMHO, OSC is practically useless for audio software control
purposes without some kind of signal layer like libmapper provides, so I'm
all for helping its adoption, even if I do seem a little Gung Ho by
implementing my own. It's just usually faster for me to do it myself than
deal with external dependencies.

I'll just have a look through your points...
>
> > 1). Liblo can't automatically assign more than 16 port numbers per
> > nominal second because the random number generation is based on
> > seconds since epoc. I think I've seen patches for this already on the
> > list. I just want to emphasize that a fix should definitely go into
> > the next release because right now I have to throttle server creation
> > to work around it.
>
> Definitely an issue, the code has a big comment saying that it should
> be improved but I never had an issue since I don't use random ports
> very often. Should really at least use a seed based on microseconds or
> something. I'll look back to see what patches have been proposed that
> I might have missed.
>

Just adding + getpid() in the equation would probably fix it. However, I
think one of the patches I saw relied on the OS to assign the port number,
which is probably even better.


> > 2. Bi-directional TCP is lacking, and it would be nice to have.
>
> Main problem here is API.  I'm not sure how it should be done in terms
> of how specific the relationship between a server and address.  There
> were some tentative ideas on the list previously but nothing concrete.
>  Something about lo_address_new_for_server() or something to that
> effect, or maybe lo_server_get_address().. hm. Or maybe
> lo_send_message_from() would be enough to do this.
>

I don't see what lo_send_from couldn't.


>
> > 3. There's no call that I can see in the API to (always) get an IP
> > address out of a lo_address handle.
>
> There is lo_address_get_hostname() which returns a string that could
> be passed into gethostbyname().  It could be nice to add a function
> that returns the already-resolved address, although it would have to
> smoothly handle both IPv4 and IPv6.
>

Specifically, my issue has to do with storing peer addresses in tables and
comparing them with incoming messages. Even just an API function to compare
two lo_addresses would be fine, but I think getting the IP is more general
(and yes I know I'm ignoring NAT and all that stuff).

> 4. I'm not sure that I understand why lo_send can't always behave like
> lo_send_from.

 I'm not sure what you mean here, lo_send() doesn't take the same
> arguments as lo_send_from()?  The idea is to be able to send a message
> that is not associated with a server.
>

You're right. My fault. Let me say it another way: I don't see why
lo_send() should be in the API ;-)


>
> > 5. Multithreading semantics aren't articulated in the documentation.
> > Is it save to call lo_send_from on the same server that's being recv'd
> > on in another thread?
>
> Documentation could be improved.  Personally I'm not a fan of using
> any threading with liblo, I try to keep my liblo calls on the same
> thread, so I never use the lo_server_thread API.
> As for the specific question, lo_send_from() only accesses the
> server's fd, which doesn't change so I can't think of any threading
> issues here.
>

I'm not really talking about lo_server_thread (I don't use it either). Just
about what is threadsafe and what isn't.

Hi J.,

Nice feedback and great-looking project.  It actually reminds me a
little of what we're working in my lab, although the goals are
different, I wonder if there might be some common ground.

Our "big project" with liblo right now is libmapper, a library for
managing "mapping connections" between programs.  This is a little
different than session management -- in fact managing restoration of
state is a current issue for us, so it's nice to see ideas like you
show in that video, maybe we could use something like that.

Basically libmapper is about having multiple processes that can send
OSC messages to each other, however instead of each process having to
know what kinds of messages are valid for one other, the idea is that
each process announces on a multicast bus what messages they support
for input and output.  Then we use a GUI to instruct one device to
start sending messages to another, with some optional transformation
of the data.  So the devices never actually send their output message,
instead they transform it to the format required by the destination.
It's all decentralized and works across networks.  The idea is to
build up a bit of an ecosystem of libmapper programs for different
kinds of input devices and audio software, so that any device can be
mapped to any synthesizer.

Anyways, could be interesting for you, dunno. If you want more info,
check http://libmapper.org

I'll just have a look through your points...

> 1). Liblo can't automatically assign more than 16 port numbers per
> nominal second because the random number generation is based on
> seconds since epoc. I think I've seen patches for this already on the
> list. I just want to emphasize that a fix should definitely go into
> the next release because right now I have to throttle server creation
> to work around it.

Definitely an issue, the code has a big comment saying that it should
be improved but I never had an issue since I don't use random ports
very often. Should really at least use a seed based on microseconds or
something. I'll look back to see what patches have been proposed that
I might have missed.

> 2. Bi-directional TCP is lacking, and it would be nice to have.

Main problem here is API.  I'm not sure how it should be done in terms
of how specific the relationship between a server and address.  There
were some tentative ideas on the list previously but nothing concrete.
 Something about lo_address_new_for_server() or something to that
effect, or maybe lo_server_get_address().. hm. Or maybe
lo_send_message_from() would be enough to do this.

> 3. There's no call that I can see in the API to (always) get an IP
> address out of a lo_address handle.

There is lo_address_get_hostname() which returns a string that could
be passed into gethostbyname().  It could be nice to add a function
that returns the already-resolved address, although it would have to
smoothly handle both IPv4 and IPv6.

> 4. I'm not sure that I understand why lo_send can't always behave like
> lo_send_from.

I'm not sure what you mean here, lo_send() doesn't take the same
arguments as lo_send_from()?  The idea is to be able to send a message
that is not associated with a server.

> 5. Multithreading semantics aren't articulated in the documentation.
> Is it save to call lo_send_from on the same server that's being recv'd
> on in another thread?

Documentation could be improved.  Personally I'm not a fan of using
any threading with liblo, I try to keep my liblo calls on the same
thread, so I never use the lo_server_thread API.
As for the specific question, lo_send_from() only accesses the
server's fd, which doesn't change so I can't think of any threading
issues here.


Steve

Hello Stephen,


On 24 févr. 2012, at 07:09, Stephen Sinclair wrote:

> Thanks for the patch! I'll review it shortly, sorry I didn't get to
> your email until now.

Thank you for reviewing the patch!
I wish you good luck for your 'little PhD thesis work' :)


> I'm starting to pay some attention to the bug list and some features
> I've been planning to implement, because I'd like to do release
> relatively soon. (Meaning, within a couple of months. I'd like to say
> sooner, but I'm also trying to finish a little PhD thesis on the
> side!)  So if anyone has ideas / bugs fixed / features they'd like,
> now's a good time ;)

That's great.
For this release, I have no other wish than to solve the issue I have described in a previous message:

lo_address does not play nicely with socket binding and closing.

I described this in a post to liblo-devel a short while ago: http://sourceforge.net/mailarchive/message.php?msg_id=28155415.


> I was testing TCP and found something that looks like a problem, at least, I'm not sure how to solve it.
> 
> The way to reproduce it is easy:
> - start a OSC TCP server on port 8000.
> - send messages from a client on the server.
> - close the server.
> - try start the server again, it won't because the socket is already in use.
> 
> It looks like the client got hold of the socket and the server can no more bind to it.  I think there must be a problem in Liblo, can you please tell me if you can reproduce that issue, and perhaps help me find a solution?


The solution is not yet clear to me. One approach would be to periodically check that the socket is still valid, maybe by having an API that checks if the sockets are still open ; something that you could integrate in your program's run-loop...

Could you please give me your thoughts on this?


Best Regards,
Camille

Hi Steve,

I just thought I'd chime in here. I'm developing something pretty big
(http://lists.linuxaudio.org/pipermail/linux-audio-dev/2012-February/032830.html)
with liblo (0.26) right now and the most annoying things to me are:

1). Liblo can't automatically assign more than 16 port numbers per
nominal second because the random number generation is based on
seconds since epoc. I think I've seen patches for this already on the
list. I just want to emphasize that a fix should definitely go into
the next release because right now I have to throttle server creation
to work around it.
2. Bi-directional TCP is lacking, and it would be nice to have.
3. There's no call that I can see in the API to (always) get an IP
address out of a lo_address handle.
4. I'm not sure that I understand why lo_send can't always behave like
lo_send_from.
5. Multithreading semantics aren't articulated in the documentation.
Is it save to call lo_send_from on the same server that's being recv'd
on in another thread?

That's all I can think of right now ;-)

Anyway, I'm glad you're getting back into the project (I'm doing
something similar with mine) and I'm looking forward to the new
release!

On Thu, Feb 23, 2012 at 10:09 PM, Stephen Sinclair <rad...@gm...> wrote:
> Hi Camille,
>
> Thanks for the patch! I'll review it shortly, sorry I didn't get to
> your email until now.
>
> Nico: I'll take a look at shutdown.  It is called in one place, in
> address.c, but somehow it did not make it into the rest of the places
> where closesocket() is called.
>
> I'm starting to pay some attention to the bug list and some features
> I've been planning to implement, because I'd like to do release
> relatively soon. (Meaning, within a couple of months. I'd like to say
> sooner, but I'm also trying to finish a little PhD thesis on the
> side!)  So if anyone has ideas / bugs fixed / features they'd like,
> now's a good time ;)
>
> Steve
>
> On Fri, Feb 17, 2012 at 3:52 AM, Camille Troillard
> <ca...@os...> wrote:
>> Hi,
>>
>> When a liblo server is configured with a TCP socket, it manages one listening socket and a list of streaming sockets.  The code to read from TCP sockets is in server.c, in lo_server_recv_raw_stream, line 665.  In this function, is an event happened on the listening socket, we call the function accept, and then if everything went fine, proceed to reading the first packet.
>>
>> There is a problem that causes my application to hang while waiting for the first packet of data, just after a connection has been accepted.  In fact, once a socket is accepted, liblo should not try to read from it, but instead give up control to the application.
>>
>> Attached is a patch that attempts to fix that.  I hope I got the logic right.
>>
>>
>> Best,
>> Cam
>>
>>
>> ------------------------------------------------------------------------------
>> Virtualization & Cloud Management Using Capacity Planning
>> Cloud computing makes use of virtualization - but cloud computing
>> also focuses on allowing computing to be delivered as a service.
>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hi Camille,

Thanks for the patch! I'll review it shortly, sorry I didn't get to
your email until now.

Nico: I'll take a look at shutdown.  It is called in one place, in
address.c, but somehow it did not make it into the rest of the places
where closesocket() is called.

I'm starting to pay some attention to the bug list and some features
I've been planning to implement, because I'd like to do release
relatively soon. (Meaning, within a couple of months. I'd like to say
sooner, but I'm also trying to finish a little PhD thesis on the
side!)  So if anyone has ideas / bugs fixed / features they'd like,
now's a good time ;)

Steve

On Fri, Feb 17, 2012 at 3:52 AM, Camille Troillard
<ca...@os...> wrote:
> Hi,
>
> When a liblo server is configured with a TCP socket, it manages one listening socket and a list of streaming sockets.  The code to read from TCP sockets is in server.c, in lo_server_recv_raw_stream, line 665.  In this function, is an event happened on the listening socket, we call the function accept, and then if everything went fine, proceed to reading the first packet.
>
> There is a problem that causes my application to hang while waiting for the first packet of data, just after a connection has been accepted.  In fact, once a socket is accepted, liblo should not try to read from it, but instead give up control to the application.
>
> Attached is a patch that attempts to fix that.  I hope I got the logic right.
>
>
> Best,
> Cam
>
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

Sorry let me rephrase :

> I'd suggest we implement closesocket as a function (not a macro) that calls shutdown on win32.
> Would you like to implement that?

"that would replace every call to closesocket by a function that would call close or, on win32, closesocket and shutdown."



Best,
Cam

On 17 févr. 2012, at 13:59, nico wrote:

>> I don't think I have changed anything regarding this matter, only the behavior when accepting a connection. 
> i didn't said that, i just would like to mention that in your patch, each call to closesocket() must include the shutdown call before in order to suit well on win32

Then this change must be made library-wide, and not only for this patch.


>> Besides, doesn't closesocket already calls 'shutdown' on win32?
> nope,

I'd suggest we implement closesocket as a function (not a macro) that calls shutdown on win32.
Would you like to implement that?


Best,
Cam

Camille,

Le 17/02/12 13:52, Camille Troillard a écrit :
> Hi Nicolas !
>
> I don't think I have changed anything regarding this matter, only the 
> behavior when accepting a connection.
i didn't said that, i just would like to mention that in your patch, 
each call to closesocket() must include the shutdown call before in 
order to suit well on win32
>
> Besides, doesn't closesocket already calls 'shutdown' on win32?
nope,

best regards,
nico
>
> best,
> Camille
>
>
> On 17 févr. 2012, at 13:38, nico <sl1...@gm... 
> <mailto:sl1...@gm...>> wrote:
>
>> hi,
>> please be aware that for win32 compatibility reasons, any call to 
>> closesocket(sock) must include a shutdown(sock, SD_BOTH) before it to 
>> make the sock re-usable.
>>
>> best regards,
>> nicolas
>>
>>
>> Le 17/02/12 09:52, Camille Troillard a écrit :
>>> Hi,
>>>
>>> When a liblo server is configured with a TCP socket, it manages one listening socket and a list of streaming sockets.  The code to read from TCP sockets is in server.c, in lo_server_recv_raw_stream, line 665.  In this function, is an event happened on the listening socket, we call the function accept, and then if everything went fine, proceed to reading the first packet.
>>>
>>> There is a problem that causes my application to hang while waiting for the first packet of data, just after a connection has been accepted.  In fact, once a socket is accepted, liblo should not try to read from it, but instead give up control to the application.
>>>
>>> Attached is a patch that attempts to fix that.  I hope I got the logic right.
>>>
>>>
>>> Best,
>>> Cam
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Virtualization&  Cloud Management Using Capacity Planning
>>> Cloud computing makes use of virtualization - but cloud computing
>>> also focuses on allowing computing to be delivered as a service.
>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>>>
>>>
>>> _______________________________________________
>>> liblo-devel mailing list
>>> lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hi Nicolas !

I don't think I have changed anything regarding this matter, only the behavior when accepting a connection. 

Besides, doesn't closesocket already calls 'shutdown' on win32?

best,
Camille


On 17 févr. 2012, at 13:38, nico <sl1...@gm...> wrote:

> hi,
> please be aware that for win32 compatibility reasons, any call to closesocket(sock) must include a shutdown(sock, SD_BOTH) before it to make the sock re-usable.
> 
> best regards,
> nicolas
> 
> 
> Le 17/02/12 09:52, Camille Troillard a écrit :
>> 
>> Hi,
>> 
>> When a liblo server is configured with a TCP socket, it manages one listening socket and a list of streaming sockets.  The code to read from TCP sockets is in server.c, in lo_server_recv_raw_stream, line 665.  In this function, is an event happened on the listening socket, we call the function accept, and then if everything went fine, proceed to reading the first packet.
>> 
>> There is a problem that causes my application to hang while waiting for the first packet of data, just after a connection has been accepted.  In fact, once a socket is accepted, liblo should not try to read from it, but instead give up control to the application.
>> 
>> Attached is a patch that attempts to fix that.  I hope I got the logic right.
>> 
>> 
>> Best,
>> Cam
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Virtualization & Cloud Management Using Capacity Planning
>> Cloud computing makes use of virtualization - but cloud computing 
>> also focuses on allowing computing to be delivered as a service.
>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>> 
>> 
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel

hi,
please be aware that for win32 compatibility reasons, any call to 
closesocket(sock) must include a shutdown(sock, SD_BOTH) before it to 
make the sock re-usable.

best regards,
nicolas


Le 17/02/12 09:52, Camille Troillard a écrit :
> Hi,
>
> When a liblo server is configured with a TCP socket, it manages one listening socket and a list of streaming sockets.  The code to read from TCP sockets is in server.c, in lo_server_recv_raw_stream, line 665.  In this function, is an event happened on the listening socket, we call the function accept, and then if everything went fine, proceed to reading the first packet.
>
> There is a problem that causes my application to hang while waiting for the first packet of data, just after a connection has been accepted.  In fact, once a socket is accepted, liblo should not try to read from it, but instead give up control to the application.
>
> Attached is a patch that attempts to fix that.  I hope I got the logic right.
>
>
> Best,
> Cam
>
>
>
> ------------------------------------------------------------------------------
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>
>
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hi,

When a liblo server is configured with a TCP socket, it manages one listening socket and a list of streaming sockets.  The code to read from TCP sockets is in server.c, in lo_server_recv_raw_stream, line 665.  In this function, is an event happened on the listening socket, we call the function accept, and then if everything went fine, proceed to reading the first packet.

There is a problem that causes my application to hang while waiting for the first packet of data, just after a connection has been accepted.  In fact, once a socket is accepted, liblo should not try to read from it, but instead give up control to the application.

Attached is a patch that attempts to fix that.  I hope I got the logic right.


Best,
Cam