[PD-dev] SIGPIPE on iemnet's tcpserver

[Antoine Villeret]

2013/7/3 Roman Haefeli <reduzent at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20130703/5ac1d350/attachment.htm>