Hey all
I would like to open a datagram listening socket and be able to send back to clients from which I received messages. It seems both [netsend -u] and (obviously) [netreceive -u] actually can open a listening socket. However, [netreceive -u] can't send anything back. While [netsend -u] can send messages back, it doesn't show the source address of the incoming packets. And using [netreceive -u] for receiving and [netsend -u] for sending back doesn't work, because for the packets to arrive at the client, they need to be sent from the same port that is already occupied by [netreceive].
Yet, as long as I used TCP and iemnet, this was possible. However, as far as I can tell, it's not possible with UDP, neither with iemnet nor with Pd's built-in classes.
Is that something worth to make a feature request for?
While we're at it, it seems [netreceive] (in TCP mode) can only send back to all connected clients, but not to a specific one.
Roman
While we're at it, it seems [netreceive] (in TCP mode) can only send back to all connected clients, but not to a specific one.
Actually, a [sendto( message for [netreceive] would already allow you to build a fully functional UDP server in Pd vanilla.
BTW, there is a [udpserver] object in iemnet, but it's not really usable yet (it only allows to send messages to the last sender).
Christof
On 01.06.2021 22:55, Roman Haefeli wrote:
Hey all
I would like to open a datagram listening socket and be able to send back to clients from which I received messages. It seems both [netsend -u] and (obviously) [netreceive -u] actually can open a listening socket. However, [netreceive -u] can't send anything back. While [netsend -u] can send messages back, it doesn't show the source address of the incoming packets. And using [netreceive -u] for receiving and [netsend -u] for sending back doesn't work, because for the packets to arrive at the client, they need to be sent from the same port that is already occupied by [netreceive].
Yet, as long as I used TCP and iemnet, this was possible. However, as far as I can tell, it's not possible with UDP, neither with iemnet nor with Pd's built-in classes.
Is that something worth to make a feature request for?
While we're at it, it seems [netreceive] (in TCP mode) can only send back to all connected clients, but not to a specific one.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
One solution (which the conniption server/client and quacktrip both use in somewhat different ways) is for a "netreceive" object to wait for an incoming connection and then, once one arrives, immediately to close its own listening port and for a "nestsend" in the same patch to open a connection to the IP and port that the "netreceive" reported (via its second outlet). It's a bit complicated but gets the job done.
cheers Miller
On Wed, Jun 02, 2021 at 12:06:28AM +0200, Christof Ressi wrote:
While we're at it, it seems [netreceive] (in TCP mode) can only send back to all connected clients, but not to a specific one.
Actually, a [sendto( message for [netreceive] would already allow you to build a fully functional UDP server in Pd vanilla.
BTW, there is a [udpserver] object in iemnet, but it's not really usable yet (it only allows to send messages to the last sender).
Christof
On 01.06.2021 22:55, Roman Haefeli wrote:
Hey all
I would like to open a datagram listening socket and be able to send back to clients from which I received messages. It seems both [netsend -u] and (obviously) [netreceive -u] actually can open a listening socket. However, [netreceive -u] can't send anything back. While [netsend -u] can send messages back, it doesn't show the source address of the incoming packets. And using [netreceive -u] for receiving and [netsend -u] for sending back doesn't work, because for the packets to arrive at the client, they need to be sent from the same port that is already occupied by [netreceive].
Yet, as long as I used TCP and iemnet, this was possible. However, as far as I can tell, it's not possible with UDP, neither with iemnet nor with Pd's built-in classes.
Is that something worth to make a feature request for?
While we're at it, it seems [netreceive] (in TCP mode) can only send back to all connected clients, but not to a specific one.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
On Tue, 2021-06-01 at 15:27 -0700, Miller Puckette via Pd-list wrote:
One solution (which the conniption server/client and quacktrip both use in somewhat different ways) is for a "netreceive" object to wait for an incoming connection and then, once one arrives, immediately to close its own listening port and for a "nestsend" in the same patch to open a connection to the IP and port that the "netreceive" reported (via its second outlet). It's a bit complicated but gets the job done.
That absolutely works. And since that can be done in zero logical time, [netsend] doesn't claim any packets coming in on the port "shared" with [netreceive]. Cheers to Pd's determinism!
That opens up an a lot of new things to explore for me. Thanks!
Roman
If you want the server to reply only to the current client, [iemnet/udpserver] actually works fine (despite the error message in the console): the list method will send the packet to the source address of the most recently received packet.
However, if you need to send packets to several/all registered clients, e.g. like a game server, this doesn't work (yet).
Christof
On 02.06.2021 08:54, Roman Haefeli wrote:
On Tue, 2021-06-01 at 15:27 -0700, Miller Puckette via Pd-list wrote:
One solution (which the conniption server/client and quacktrip both use in somewhat different ways) is for a "netreceive" object to wait for an incoming connection and then, once one arrives, immediately to close its own listening port and for a "nestsend" in the same patch to open a connection to the IP and port that the "netreceive" reported (via its second outlet). It's a bit complicated but gets the job done.
That absolutely works. And since that can be done in zero logical time, [netsend] doesn't claim any packets coming in on the port "shared" with [netreceive]. Cheers to Pd's determinism!
That opens up an a lot of new things to explore for me. Thanks!
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Tue, 2021-06-01 at 15:27 -0700, Miller Puckette via Pd-list wrote:
One solution (which the conniption server/client and quacktrip both use in somewhat different ways) is for a "netreceive" object to wait for an incoming connection and then, once one arrives, immediately to close its own listening port and for a "nestsend" in the same patch to open a connection to the IP and port that the "netreceive" reported (via its second outlet). It's a bit complicated but gets the job done.
Turns out this works for light loads only. For the loads I'm interested in, the clients get "disconnected". Probably the server is sending an ICMP notification that the destination port is not ready or something like that and [netsend -u -b] on the client side terminates the "connection" (outlet turns zero).
Roman
The mrpeach [udpsend] outputs its ip and port on the second outlet on 'connect', while the[ [udpreceive] object outputs the ip and port of each received datagram, so using both you should be able to do what you want. A [udpsend] normally has a different port number to the one it sends to, but a [udpreceive] in the same Pd process can still receive on that port.
Martin
On Tue, Jun 1, 2021 at 4:57 PM Roman Haefeli reduzent@gmail.com wrote:
Hey all
I would like to open a datagram listening socket and be able to send back to clients from which I received messages. It seems both [netsend -u] and (obviously) [netreceive -u] actually can open a listening socket. However, [netreceive -u] can't send anything back. While [netsend -u] can send messages back, it doesn't show the source address of the incoming packets. And using [netreceive -u] for receiving and [netsend -u] for sending back doesn't work, because for the packets to arrive at the client, they need to be sent from the same port that is already occupied by [netreceive].
Yet, as long as I used TCP and iemnet, this was possible. However, as far as I can tell, it's not possible with UDP, neither with iemnet nor with Pd's built-in classes.
Is that something worth to make a feature request for?
While we're at it, it seems [netreceive] (in TCP mode) can only send back to all connected clients, but not to a specific one.
Roman _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Christof Ressi -
Martin Peach -
Miller Puckette -
Roman Haefeli