ok thanks for the explanation so, for now, there is now way to setup a working [udpserver] in pd right ? if so, I will stay with [tcpserver] even if I don't need tcp...
but if I could help in debugging [udpserver], I'll be happy to do so, just let me know what can I do cheers a -- do it yourself http://antoine.villeret.free.fr 2013/7/4 IOhannes m zmoelnig <zmoel...@iem.at> > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2013-07-04 13:55, Antoine Villeret wrote: > > 2013/7/3 IOhannes m zmoelnig <zmoel...@iem.at> > > > > On 2013-07-03 17:33, Antoine Villeret wrote: > >>>> so it could be difficult to use a server which doesn't accept > >>>> more than one connection... > >>>> > > > > no that's not what i meant. you can have as many connections as you > > want, but they cannot be maintained at the same time. > > > > simple example: - both clientA and clientB send a a query to the > > server - to complicate things, they do so at exactly the same time > > - but since IP is a serial protocol, they will somehow arrive one > > after each other - let's assume clientB was faster - [udpserver] > > will output the query from clientB - if the server-patch now > > immediately responds to that query, the response will be sent back > > to clientB - then [udpserver] will output the query from clientA. - > > [udpserver] will forget everything about clientB - if the > > server-patch responds immediately to that query, the response will > > be sent back to clientB - if you later "send" something from the > > server, it will still be sent to clientB (because clientB is the > > last known connection) > > > > > >> so in this case, if I understand correctly, udpserver never send > >> an answer to clientA ? > > no, it does send and answer back. > > >> I have to disconnect clientB *before* connecting clientA ? > > no. UDP doesn't know about "connections". > > >> but how clientA will know this is time to connect ? should it try > >> until the connection is accepted ? > > again, UDP is connection-less so there is no connection. > > i think the main problem here comes from the use of the symbol > "connect" for interfacing with e.g. [udpsend]. > this message is named "connect" mainly for consistency with the tcp/ip > objects. > > anyhow, when you "connect" a client to server, the client will open a > socket for this connection. the server won't know anything about this > "connection", but it will receive data on a it's listening socket. it > can use the socket to send data back (if you have routers/switches/... > inbetween, this sending back will only work for a limited amount of time). > since the server doesn't know anything about the "connection"-state of > the clients, you don't have to disconnect anything. > > > fgmasdr > IOhannes > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Icedove - http://www.enigmail.net/ > > iEYEARECAAYFAlHVZt0ACgkQkX2Xpv6ydvS1DQCg3OWfgTqDbH6P52s+1S5FOoJt > q3IAn3fxytsJlhVAmepjfXsakZIYGFiT > =djBg > -----END PGP SIGNATURE----- > > _______________________________________________ > Pd-dev mailing list > Pd-dev@iem.at > http://lists.puredata.info/listinfo/pd-dev >
_______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev