2013/7/3 Roman Haefeli <reduzent@gmail.com>
On Die, 2013-07-02 at 20:38 +0200, Antoine Villeret wrote:
> Hi roman,
>
>
> the code around networking object are some workarounds for differents
> bugs,
> the first was a crash when client number reach 32, but it seems to be
> fixed, I can't reproduce this anymore
> the second was something strange if several clients connect to the
> same server at the same time (when patch launch for example), so I add
> a timeout, if no answer in this timeout, the client disconnect
> there is also a mechanism to choose an available port at startup in
> server and the client try different port until it get a connection...

Ok, I think I understand a bit more now.

The server tries a different port when the first port is not available
right? It scans until it finds one. I don't see what the client is
supposed to do. There is some code to scan through ports, but actually
when I tested your client, it always only tried 10000. 

the client try to connect to a port if there is a server on that port, it gets a connection
if there is no server, it can't get connected and so the client tries another port.
at least it's supposed to do so... 

I don't think that dynamic ports are a good solution.  If you find a
proper way to disconnect the clients, then you shouldn't experience the
problem of a busy port when restarting the server. This only happens
when you close the server patch without disconnecting the clients.
Anyway, the port scanning of the clients would be so slow that probably
by the time they found the correct port, the initial port would be free
again (depending on OS, though).
 
yep, I'm aware that dynamic port finding is not the best solution but due to bugs related before, iemnet's [tcpserver] used to crash pd.
And so port stay busy until a certain timeout (here 60 sec), finding a new available port restores the installation in a working state more quickly.


Then I think your way of testing might expose bugs that you wouldn't
experience in real life. I mean that is good for bug reporting, but it
isn't really meaningful to connect many clients in the same instance of
Pd, even less so to connect them all in zero logical time. If you would
run your clients in different instances of Pd (what I think is your plan
anyway), you wouldn't have to find workarounds for issues exposed by
running clients in the same instance.

yes of course my patches stress the server a lot 
but it's only to delimit where the bug is.
and at least it works for that :-)


I figured you can only properly disconnect all clients with
[net/tcpserver]. Unlike [iemnet/tcpserver], it has no 'disconnect'
method. So you have to disconnect each client separately.
[iemnet/tcpserver] is supposed to disconnect all clients with
'disconnect', but actually the [iemnet/tcpclient]s seem to ignore it and
keep their connected state (outlet 3 doesn't switch to 0). Finishing
sessions seems generally to be still a problem with iemnet. Also when a
client disconnects, the server often doesn't change the number of
connected clients. The net library seems much more robust in this
regard.

I simplified your patches a lot and as simple as they are, they seem to
work fine here. Note about the server: you need to disconnect all
clients before you close the server patch. This will the leave the
network socket in a clean state and you will be able to occupy that port
immediately again. The client tries to connect at a rate of one try per
second. In case it gets disconnected by the server, it waits 5 seconds
before trying to connect again. This gives you time to disconnect all
clients and shutdown the server properly.

hum, I can't be sure that all clients are properly disconnected because the pd where the server is could crash at anytime for lots of other reasons... 

Behind that there is a shared memory id manager.
On the server side, I generate ids then try if I can get memory segment, if so I send this id to all clients that need it.
When a client gets connected, it asks for an id for a give path (a string like /video_server or /cam1) if it exist the server send it back to the client, if no, it generates a new id.
 


> all of this is quite complex for a not so difficult task : I want to
> make several instance of Pd talking to each other on one machine
>
>
> I started with udpsend/udpreceive but I found no way to do broadcast
> on localhost

You mean broadcast on all ports? I don't think that something like that
exists.

I mean listening several clients on the same port on the same machine (that is a server, right ?)
 

> and I do need to have lots of clients
> multicasting is not a solution because it need to have a working
> networking interface

If you want to run many instances of Pd on localhost, then multicast
can't help you. It is about sending data to many clients on different
IPs at the same time. You want to send to many clients on localhost.

> then I tried udpserver which doesn't work (at least the version in the
> pd's SVN)
> then I switch to tcpserver and I got a lots of troubles...

Things look good as long as you think you only need streams. As soon as
you figure out that you need to send packets between your instances of
Pd, things get really complex wit [tcpserver].

no, I don't really need stream
I choose [udpserver] because it's the only server in the iemnet's folder that works
yep, it's a stupid reason... I should better try another udpserver somewhere else... :-)


> I will try out iohannes version of iemnet and I'll also investigate
> those bugs

As of today, both libraries net and iemnet have known bugs. My examples
use net because [iemnet/tcpserver] can't disconnect clients.

> but other (simpler) solutions are welcome :-)

See attachment. I tested them with Pd-extended 0.43.3 on Ubuntu 12.04

thanks for all

best

antoine 

Roman