Greetings All,
I am using the RL_ARM TCP net library in order to establish a connection with the LPC2468.
I have the following code to initialize the UDP connection:
static U8 retval = 0xFF; udp_soc = udp_get_socket (0, UDP_OPT_SEND_CS | UDP_OPT_CHK_CS, udp_callback); if ( udp_soc != 0 ) { retval = udp_open(udp_soc,0); }
The implementation of the udp_callback function is:
delayMs(500); Buffer = udp_get_buf (count); memcpy(Buffer, ptr,count); retval = udp_send (udp_soc, _remip, _remport, Buffer, count); return (0);
_remip is the port that is autoselected, and _remip is the ipaddress passed to the function.
The udp test program that I have is ServerTalk, and allows me to connect to an ip adress and not specify a port, however, any data I attempt to send to the UDP connection is never recieved in my code.
I have switched things around, where I specify a port in the code, and it works better, but really want to not have to do that.
Has anyone ever run into similar issues, or am I doing something fundamentally wrong?
Any help is appreciated.
Thanks,
When you are acting as a server, you should specify the port number on which you expect communication to occur - The 'other side' must know what port to send the message to.
In the callback, you will receive (along with the data) the IP address from where the message came and the port number on which it arrived. If you want to send a response, you use this information so that you can tell where that response should be sent.
When you are acting as a client, you will send a message to a specific IP address on a specific port number. In this case, the port number to which any response should be sent would not (normally) be important, so you can as the TCP stack to automatically allocate a port number.
Per's comment of:
"But the server itself must always have a hardcoded port, or the client wouldn't be able to know what UDP port to send the initial message to."
Is mostly correct. It is important that both client and server agree on a particular port number, but the server does not have to have a hardcoded port to achieve this. It is not unusual for the port number to be a configurable option.
Correct. I shouldn't have used the word "hardcodeed" but maybe "static" or "predefined".
It is actually even possible for a server to have a dynamic port - but then the client must have other means (such as another port to request configuration info from or a "man-in-the-middle" or similar) to find out what this port is.
But when the client starts to communicate it may specify its own port or let the stack find an available port. But it must know what port to use on the server side. And the server must already listen on this port, to be able to receive any data from the client.