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,
I don't use the Keil stack, so I'm a bit confused here. Do you think you have written the server side (the one that listens to connects and may send back an answer) or the client side (the side that connects to a server, and potentially waits for an answer).
_remip, _remport would be the IP number and port for the remote side, and the names suggests that it is the server who gets to know the IP number and port of the client who did connect to the server.
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.
The open issue here is what you mean with "and allows me to connect to an ip adress and not specify a port". A client must always specify a destination port. But it can let the TCP stack select the local port. A server must always listen on a fixed port. And if sending an answer back, it can check the source port and source IP of the received data to know where to send answers back.
So what did you mean with "and not specify a port"? What side did you talk about? And about initial message, or response back from server?
First of all, thank you for responding to my post.
Let me see if I can shed some light on this.
In the LPC2468 I have written what I believe to be the server.
The client side for now, is "ServerTalk" a freeware app that I have been provided.
_remip and remport are known when a client sends data to the server
According to the Keil documentation at http://www.keil.com/support/man/docs/rlarm/rlarm_udp_open.htm
You can specify 0 for the port, and the library will assign a number automatically. Perhaps I am misunderstanding what that means.
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.
How about providing a link so that people can see what you're referring to...?
The name's a bit ambiguous - it could be a Server that Talks, or it could be something that Talks to Servers...
Here's a UDP test tool that I've found useful: www.sctm2m.com/udptesttool.html
Also one for TCP: www.sctm2m.com/tcptesttool.html