Set sender and receiver port of UDP

Hello Guys,

I have HD224 Player and we have a requirement of to trigger player (Play, stop, etc..) using UDP command and player send back acknowledge over UDP also.  I have configure UDP 5000 port configuration as per attached snapshot. Currently player triggered and send acknowledge over UDP was working well.

But the problem was when we triggered player using UDP command from my PC (using packet sender software) we can see sender and receiver port are same (5000) but acknowledge packet received from Player have different source port (38223) even though we have configured 5000. (snapshot attached). Player IP address is

Anyone please help to resolve this issue?  




1 comment

  • 0

    Outside of dedicated persistent connections, it's rare for a server (receiver) to be selective about the source port the client (sender) uses.

    Limiting requests by source port reduces the client's ability to make parallel requests.  Port-triggering tracks the source port to send a response back (usually on the next incremental port), but again that's usually used for instancing a persistent connection to something like a game server, and that's largely been replaced by UPNP and web sockets in modern times.

    For example, if a web server only accepted requests originating from port 80 the client, the client would only be able to make one request at a time without having to track extra serialization and response verification which TCP/IP already does, if you don't put implement extra restrictions like this.

    Quite a few of the lower-numbered ports are well-known ports reserved for specific server uses, and only one process can use a port at a time - so it's bad practice to use those ports to send, which leaves only the epheremal ports available for use.

    If you think of ports like a traditional telephone bank (physical lines, not VoIP), a lot of the phone numbers are reserved for specific types of calls, so you shouldn't be placing calls on those lines, which leaves only a subset for whatever random communication you need to make, whether that's ordering a pizza or calling the bank to check your balance.
    The telephone number you use to make those outgoing calls would vary depending on what extra phone line you use.  If the bank only accepts calls from a specific telephone number, that means only one person from the telephone bank can make check their balance at a time and anyone else who wants to check their balance will have to wait until whoever's using that line is done.

    The server should respond to the player at the player's UDP Receiver port.  The player will not initiate an outgoing message from its UDP Receiver Port, because it cannot simultaneously listen for incoming messages while using the same port to make outgoing connections.  The outgoing messages are sent to the UDP Destination Port on the receiver, but the source port used to send the message will be whatever epheremal port is free.  Since UDP in particular is "fire and forget" the port won't be tied up for long, but there's no guarantee of a particular port being used.

    If you must send an outgoing request from the player using a specific source port, you can do so via BrightScript with roDatagramSocket or the corresponding BrightSign-JavaScript object, BSDatagramSocket in a HTML page.  Remember to only keep the port bound as long as needed, or have a centralized page/plugin to reuse the same port for subsequent requests, especially if you need to send multiple messages from the same port.

    Also note that if you do this and you expect responses on the same port used to send, you need to immediately unbind the port and start listening else you'll miss the response.  If you're expecting a response on the next incremental port or some other port derived from the send port you will also need to build your own listener (server) in BrightScript or JavaScript and process those incoming messages on your own as BrightAuthor won't see them.  You could just resend the incoming message to the BrightAuthor UDP Receiver Port, assuming you can tell what they're in response to though.

    Friendly reminder, the community forum is intended for user-to-user discussion.  It is not regularly monitored. For troubleshooting problems and to ensure a timely answer from a BrightSign representative, please submit a support ticket

Please sign in to leave a comment.