can't specify udp
soure port

@midi I hope this helps......... udp.zip
Done in a rush and I am away for the next 24hrs.
Please post again if it is not what you need and I will help when I return...... or someone else will chip in before then.

The message sent back cannot be a port chosen at random by the server as the client will not know on which port to listen.
But you could send an osc message to the server telling it to which port it should connect.
That would mimic a browser requesting information from a server over http.
udp2.zip
David.

@whale-av Thanks again.Many apps(ipad,pc mac)have been developed to do that. I wonder PD can do that.

@midi You might have some success with the maxlib library...... chat.zip
What program is running on the server? In Linux? or another os? Will it even understand osc or is it going to receive messages in some other format? What is the end purpose?
David.

@midi I've not seen a way to specify the source port, but there's this paragraph in the [netsend] help that suggests that you can get UDP responses back on that unknown random port. I've never gotten it to work though.

@jameslo I hadn't seen the new [netsend]
It must be using the bidirectional qualities of the socket so maybe one can use [netsend] at both ends.
David.

@whale-av I can't get that to work either. At the receiver, if I reply using [netsend] I have to specify an IP address and a port--leave out the port and I get an error msg; leave out both and nothing happens. The help file implies that one should reply via the [netreceive] that handled the message, but you get an error msg if you try under UDP.

I'm only bringing this up because @midi seems to have a hard-coded UDP receiver on the server that replies on the same UDP connection, so I was wondering if [netsend -u] works with it. TBH I wasn't aware that there were source ports for UDP messages and I don't know if it even makes sense to talk about a UDP "connection".

@jameslo Yes, a really stupid idea from me. [netsend] creates the socket so it cannot be done twice on the same port.
You are correct about using TCP. In the help file for [netsend] it says TCP only for the bidirectional socket...... so not helpful for @midi...... a shame as there is no reason it could not be good for UDP.

What @midi has found...... that the server replies on a random port.... is the problem that makes no sense..... how can the client know what port to open.

If the random port range is known then a redirect could be set on a router, but that would probably need the server to be on the wan side of the router, as it would be normally as a web server...... but not if it is a NAS.

The mrPeach library had some objects for HTTP comms..... [tcpclient] and [httpreceive] and [httpreq] that might be able to deal with this problem........... but again they are not UDP.
Maybe TCP and not UDP is acceptable.
David.

As I understand it, there is no way for any app to guarantee the port from which messages are sent. If the desired outgoing port is busy, the app has only two ways to handle it: choose a different port (which may conflict with the receiver's expectation), or exit with error.

So, AFAICS, the receiving app must be capable of handling multiple possible source ports.

In SuperCollider, upon startup it tries to get port 57120 for UDP send and receive. If this fails, it tries 57121 and so on until it finds an open port. From that point forward, messages sent to SC should be addressed to that port, and messages sent from SC will come from the same port number. This at least is deterministic: you can ask it NetAddr.langPort and be sure messages will come from here (but you can't be 100% sure this will be the same on every startup, as it's possible to have multiple sclang processes running at the same time, and they can't all use the same port).

IMO this is easier to manage than Pd's "choose a random outgoing port" -- I have no idea why so many apps do it that way. It's a pain. At least SC's way, you can anticipate a range of ports that are likely to be used.

In any case, I don't think it will work to write the server app to filter messages on one and only one port number. You'll probably at least need some handshaking logic for the server to read the port number.

hjh

I've found running this from the shell:

sudo tcpdump udp -X

is helpful when debugging UDP packets from MobMuPlat, etc. PD (or any other receiving app) doesn't even need to be running. It will display all the UDP traffic, but it's pretty easy to find your messages from the babel. It works with tcp, too (substitute "tcp" for "udp").

It's come in handy, especially when nothing is coming through, and you don't know where to start...

(Linux here, but there's sure to be something similar for every OS.)