Hi Martin, 

Thanks for your reply.

For now, I increase the MAX_CONNECT value and I also make each client disconnecting after they receive expected data, and they connect again if needed.

But I experience another issue.

If Pd crashes for any reason, the socket stay in a TIME_WAIT state and if Pd restarts asap, the port may not be available and thus tcpserver can't bind to it.

I have to wait until the end of TIME-OUT before restarting Pd.

I found a solution [1] (restart network service) to release the socket, so that tcpserver can bind to the same port again.

But it could be good to handle this inside Pd isn't it ?

So I guess two ways : 

1- according to WMR in [1], we can set SO_REUSEADDR via setsockopt(2), but I don't know if this possible without lots of code rewriting...

2- tcpserver could also have a [bind <port_number>( message to select the port to bind to and send out error through its right outlet to notice if port is available or not, so that we can try to bind again until a port is available.

But I'm not very familiar with sockets, so maybe I'm wrong...

Cheers

Antoine 

[1] http://serverfault.com/questions/329845/how-to-forcibly-close-a-socket-in-time-wait

--
do it yourself                      
http://antoine.villeret.free.fr

2013/5/19 Martin Peach <martin.peach@sympatico.ca>

Yes, it seems that the routine that adds new connections doesn't check to see if it has passed the number of connection slots.
There are MAX_CONNECT slots allocated when [tcpserver] starts.

Thanks for finding this bug!

There is no reason to limit the number of connections to 32 except to not use up memory.
I think it could be changed to either dynamically add space for new connections without limit or set MAX_CONNECT with a creation argument.

For now you could recompile it with MAX_CONNECT set to another value. (At some point the OS will run out of sockets. Before that Pd will slow down...)

#define MAX_CONNECT 10000


Martin

On 2013-05-18 17:37, Antoine Villeret wrote:

so I reply to myself...

I found this in the code of both tcpserver.c :
#define MAX_CONNECT 32 /* maximum number of connections */

which could be an answer embryo

so, I shouldn't make more than 32 connections on the same tcpserver, ok,
but why ?
is there a good reason to fix this to 32 ?

and this doesn't tell me why it crashes...
reaching the MAX_CONNECT should handles in the code isn't it ?

cheers

a

--
do it yourself
http://antoine.villeret.free.fr


2013/5/16 Antoine Villeret <antoine.villeret@gmail.com

<mailto:antoine.villeret@gmail.com>>

    hi all,

    I've just notice [tcpserver] crashes when the 34th client try to connect
    both iemnet and mrpeach are affected

    iemnet version send a strange number on the 33th connection
    (like 2.8686e+07) and crashes on the 34th


    here is a gdb output for iem :
    Program received signal SIGSEGV, Segmentation fault.
    0x00007fffcdbca746 in tcpserver_connectpoll (x=0x66994c0) at
    tcpserver.c:503
    503     x->x_sr[i] = y;
    (gdb) watchdog: signaling pd...


    and for mrpeach :
    Program received signal SIGSEGV, Segmentation fault.
    0x00007fffcddaf585 in tcpserver_connectpoll (x=0xadfc1c0) at
    tcpserver.c:1113
    1113       outlet_float(x->x_sockout, x->x_sr[i]->sr_fd);/* the
    socket number */
    (gdb) watchdog: signaling pd...


    it happens on ubuntu 12.04 64 bit
    pd 0.44.2
    and SVN update today

    i'm certainly doing something wrong to get this (like keeping
    clients connected all the time)
    but a crash is never welcome...

    cheers

    antoine
    --
    do it yourself
    http://antoine.villeret.free.fr

_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list