gregorbaumann

does anybody knows how to set the udp send port number on the max msp side when using osc/udp send object ?

Hi,
does anybody knows how to set the udp send port number on the max msp side when using osc/udp send object ?

udp-send-port-osc-object

Its explained in the help file. Nobody could do it better than that...

I maybe didnt express myself correctly. I use Maxmsp as an OSC client. On the other side there is an OSC server that replies to the max max msp client on the udp port number that was used to send the OSC request. That is my question : is it possible to define the port number that is used to send the request ? And not the one of the target of the message.

I don't see OSC as a client/server setup. You just send on 8000 and receive on 9000, the other side does it maybe the other way round. Any client has to decipher all messages it receives...

If you want to send to different receivers, you can send it through different ports and setup the receivers differently...

Max is client and server at the same time...

I don't see OSC as a client/server setup. You just send on 8000 and receive on 9000, the other side does it maybe the other way round. Any client has to decipher all messages it receives...
If you want to send to different receivers, you can send it through different ports and setup the receivers differently...
Max is client and server at the same time...


I understand your question and no, there is no way to tell 

 the outgoing port to use (at least, there is no way that I was aware of). In most cases, mono-directional networking tools will bind to `port 0' for outgoing connections (which means that the OS assigns a freely available random outgoing port), and I think 

 does just the same. However, even if you could find out the outgoing port (which you can do with, for example, Wireshark) you couldn't really use that information, as it usually changes with each message...

I understand your question and no, there is no way to tell [udpsend] the outgoing port to use (at least, there is no way that I was aware of). In most cases, mono-directional networking tools will bind to `port 0' for outgoing connections (which means that the OS assigns a freely available random outgoing port), and I think [udpsend] does just the same. However, even if you could find out the outgoing port (which you can do with, for example, Wireshark) you couldn't really use that information, as it usually changes with each message...

What is the second parameter to udpsend other than defining the outgoing port?

What is the second parameter to udpsend other than defining the outgoing port?
I still don't see any problem here...


the second parameter defines the port on which the 

 machine listens to incoming messages. The question of the OP is whether there was an option to set the port used by the 

 machine to send those same messages. My answer was that, AFAIK, there is no way to set this port from Max.

When you send an UDP message, it contains both the 

 ports within the packet header, this is why I wrote that one could gather this information, if needed, with a network protocol analyser (eg. Wireshark), but since mono-directional solutions usually don't expect any response from the remote host, the source port number is usually set to 0 in these cases.

It might sound confusing at first, but one must distinguish between the 

 used by the sender host to send the messages out and the 

 on which the receiver host is listening. In most cases, the outgoing port is simply irrelevant, but in very special cases (like the one described by the OP) you simply can't live without knowing the so-called source port. I've worked a few years ago with an ethernet-controlled microcontroller which also used the source port of the sender machine to send back the messages, and it took us a while to solve the scenario (in fact, this was the initial project which led me to launch my library).

the second parameter defines the port on which the remote machine listens to incoming messages. The question of the OP is whether there was an option to set the port used by the sender machine to send those same messages. My answer was that, AFAIK, there is no way to set this port from Max.

When you send an UDP message, it contains both the source and destination ports within the packet header, this is why I wrote that one could gather this information, if needed, with a network protocol analyser (eg. Wireshark), but since mono-directional solutions usually don't expect any response from the remote host, the source port number is usually set to 0 in these cases.

It might sound confusing at first, but one must distinguish between the outgoing port used by the sender host to send the messages out and the incoming port on which the receiver host is listening. In most cases, the outgoing port is simply irrelevant, but in very special cases (like the one described by the OP) you simply can't live without knowing the so-called source port. I've worked a few years ago with an ethernet-controlled microcontroller which also used the source port of the sender machine to send back the messages, and it took us a while to solve the scenario (in fact, this was the initial project which led me to launch my library).

Thanks for support, that'exactly what I was looking for.

You're welcome. Actually, I wonder how you would solve this scenario, so if you come up with a solution, I'd be interested in reading about it.

BTW, in my case, I finally managed to re-write the microcontroller itself to send the responses on a specified port instead of using the source port of my machine. However, if you don't have access to the source code of your OSC server, then this solution wouldn't work.

However, if your OSC server accepts TCP-based bi-directional connections as well, then you may experiment with the following solution, based on tools from The sadam Library:

The server settings related to the servers answer port would have to be accessible in the next update of the product, called meyersound galileo. The tcp is the actual spare solution and i'm just going to test it this afternoon.

It is a spre solution that has to be conform to the OSC over Ip definition that means I have to reformat the message to conform to it. Pure binary doesn't work.

http://archive.cnmat.berkeley.edu/OpenSoundControl/OSC-spec.html

@GB the patch that I made uses, in fact, OSC. Here's why: the purpose of the first pair of 

. The reason is that my objects don't use OSC per se, but of course, they can catch any binary stream, including an OSC-formatted one. Then, this stream gets forwarded to the remote server by 

, which is a bi-directional TCP object, and as such, it would catch the stream sent back by the remote server. Now, the purpose of the last pair of objects (

I know it's a bit tricky and it's a bit like a `dirty workaround', but at the end of the day, you get an OSC-formatted bi-directional TCP patch. So, the only real question remains, whether your server accepts TCP as well, or not?

@GB the patch that I made uses, in fact, OSC. Here's why: the purpose of the first pair of [udpsend]-[sadam.udpReceiver] is to catch the OSC stream created by [udpsend]. The reason is that my objects don't use OSC per se, but of course, they can catch any binary stream, including an OSC-formatted one. Then, this stream gets forwarded to the remote server by [sadam.tcpClient], which is a bi-directional TCP object, and as such, it would catch the stream sent back by the remote server. Now, the purpose of the last pair of objects ([sadam.udpSender]-[udpreceiver]) is to decode the OSC stream itself.

the Server is able of getting both UDP and TCP OSC commands on one of his ports. The only difference is that it needs a four byte big endian length-in-bytes field before the osc packet like it is described in CNMAT's OSC 1.0 Standard. Keeping up trying.

Hi,
the Server is able of getting both UDP and TCP OSC commands on one of his ports. The only difference is that it needs a four byte big endian length-in-bytes field before the osc packet like it is described in CNMAT's OSC 1.0 Standard. Keeping up trying.

Thanks all for this post - very informative. @GREGORBAUMANN - could you shed a little more light on how to format for TCP - I have it working fine with UDP - but i need TCP for this application. I know the packet size has to go first - but I am confused on how to do that.

For example - I have the OSC command - /TransportState 2

47 84 114 97 110 115 112 111 114 116 83 116 97 116 101 0 44 105 0 0 0 0 0 2

I suspect the packet length is 44, but simply shifting that to the front didn't seem to do it. Any help would be greatly appreciated!

Thanks all for this post - very informative.  @GREGORBAUMANN - could you shed a little more light on how to format for TCP - I have it working fine with UDP - but i need TCP for this application.  I know the packet size has to go first - but I am confused on how to do that.

I suspect the packet length is 44, but simply shifting that to the front didn't seem to do it.  Any help would be greatly appreciated!

The packet length is 24 and is expressed like that.

0 0 0 24 47 84 114 97 110 115 112 111 114 116 83 116 97 116 101 0 44 105 0 0 0 0 0 2

In attachement, the example of a ping request.

Thus using the fantastic Sadam TCPClient.

Hi
The packet length is 24 and is expressed like that.

That's fantastic - totally connected the dots for me. Beers on me next time you pass thru NYC!

That's fantastic - totally connected the dots for me.  Beers on me next time you pass thru NYC!

im having the exact challenge now , trying to control a lighting program MPC , using virtual loopback network adapter,

the client MPC is only listening in one port over one adapter , so i have many [udpsend] objects sending to the same ip

but i cant manage the OSC source address to have each object , or patch for example , send udp using a different source.

i think the client can only receive udp , no tcp ,

im having the exact challenge now , trying to control a lighting program MPC , using virtual loopback network adapter,
the client MPC is only listening in one port over one adapter , so i have many [udpsend] objects sending to the same ip
but i cant manage the OSC source address to have each object , or patch for example , send udp using a different source.
i think the client can only receive udp , no tcp ,
any info on that subject?


udp send port osc object