|
From: Stephen S. <rad...@gm...> - 2011-09-30 15:42:24
|
On Fri, Sep 30, 2011 at 9:59 AM, Camille Troillard <ca...@os...> wrote: > I think I understand the problem: > > As long as the client has instances of lo_address and that lo_send has not encountered any error, the socket is bound in some way, which prevents any new server to be opened on the same port. The server definitely does keep a list of sockets for incoming TCP connections. I added this functionality so that connections could be persistent, since previously they had to be closed and opened for every OSC packet. The address has one socket, and it may keep the socket open if it doesn't notice yet that the other side is closed. There are often weird issues with waiting for sockets to time out. I don't know if this is such a case. I don't know whether the address keeping the socket open would stop a server from being able to bind that port for receiving. Will have to test. > Consider this scenario: > > - Client sends to Server > - Server is closed > - Client tried to lo_send -> results in an error. > > Now I can opened a new server on the same port. So you are saying that the address's socket is only closed when it tries to send and notices that there is no longer a receiver-side socket connected? > Does it suggest that I should get rid of the lo_address every time a message has been sent? My application keeps track of lo_addresses and reuse them. That is the desired behaviour, hopefully you don't need to change your application. :) In the above you describe that the lo_send fails when the server was closed, wouldn't that imply that you only need to re-create the lo_address only when lo_send fails, not every time you send a message? In any case, I will try to review the retry logic in address.c. Should it retry to open the connection at least once before reporting failure, or is failure on connection closed a reasonable behaviour? > Thanks for any pointers, I'd love to have this TCP layer working robustly. Me too! Thanks (again) for the great bug report! Steve |