2013/7/3 Roman Haefeli <[email protected]> > 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 > >
_______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
