-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2013-07-03 17:33, Antoine Villeret wrote:no that's not what i meant.
> so it could be difficult to use a server which doesn't accept more
> than one connection...
>
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 you can have as many "connections" as you want, but they have to be
handled atomically - on after another.
you cannot have clientA and clientB connect to the server, and make
the server send info to both simultaneously.
instead you have to adapt a query/response scheme, where each client
asks the server for piece of information.
iEYEARECAAYFAlHUSAkACgkQkX2Xpv6ydvQ7dQCfWd6Ms++xbvpFYHMUArPILPeA
fgamsdr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
fA8AoOo0uQuuQnJV5FBafbRsggXOqtzx
=29SY
-----END PGP SIGNATURE-----
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev