UDP listen for connection on port 12344

[Renasis]

Hello,

I am trying to get the Wishield to listen on a specific port for incoming connections via UDP. I was able to do something similar using TCP, using the example in the following thread. Is this possible using UDP?

viewtopic.php?f=11&t=285

My real problem is that the C# library that I am using chooses a random pc port to send the UDP message each time I run the program. I have not found where I can change this in the C# library, so I was thinking that I could set the Wishield to listen to any incoming messages on a specified port, regardless of the pc port that sent the message.

Thanks,

-ren

[GregEigsti]

Is this possible using UDP?

Yep, take a look at the UDP example in the .c file - you are looking for

Code: Select all

void udpapp_init(void)
{
   uip_ipaddr_t addr;
   struct uip_udp_conn *c;

   uip_ipaddr(&addr, 192,168,1,100);
   c = uip_udp_new(&addr, HTONS(0));
   if(c != NULL) {
      uip_udp_bind(c, HTONS(12344));
   }

   s.state = STATE_INIT;

   PT_INIT(&s.pt);
}


The port that is local to the PC (the TX port so to speak) should not matter at all - just as long as you are sending to the correct port on the remote (WiShield) side. For a network conversation there is a port opened on each side - the one that matters is the the receiving/remote end's port number. The port that the message is sent from does not (typically) matter and these port are (again typically) chosen in a "random" fashion.

My real problem is that the C# library that I am using chooses a random pc port to send the UDP message each time I run the program.

This is typical for any/all/most networking code.

Greg

[Renasis]

Greg,

Thanks for the reply. Yes, I am familiar with using HTONS(0) to connect to a pc port which is unknown initially. The problem I am having is if I have two buttons in my application which send a message to the Wishield, they will go out on two different pc ports. How could I set the connection to the new pc port w/o having to upload the code again? Do I need to delete the connection and recreate? Or is there a way to change the port for the connection?

Thanks,

-ren

[GregEigsti]

For simplicity lets leave TCP sockets out of it - but they are mostly the same.

When your PC (or WiShield) creates a socket connection for sending there is a "source port" (where the data is sent from); the device that is meant to receive the data creates a "destination port" (where the data is received). Typically the source port is picked at "random" but the destination port is set with your code - because it is the important one. The source port (on the PC in your case) is unimportant and is typically picked at "random" by the socket library; the destination port, however, is specified by your code because it must match the port that the receiver is "listening" on. In the WiShield sample code the call to uip_udp_bind() says this is the port that I am "listening" on - or receiving connections/data on. The PC must send data to that port or the WiShield will not pay attention to it.

This is analogous to "snail mail" - the source address (where a letter is sent from) is mostly unimportant; the destination address (where the letter is going to) is important. If you order an electronic goody off of the web you don't care what address it comes from (the source port) but you do care about the address that it is delivered to (the destination port).

If your C# library is changing the destination port on you (not the source port) then I'd take a look at the API to make sure that it is being used correctly or toss it as it is doing the wrong thing.

If you want each button to send to a different port on the WiShield then you will need to tell the WiShield to "listen" on two ports (destination ports) and have each button's code send to the appropriate destination port. A simpler approach would be to include a small header in the packet payload that describes what button (or functionality) sent the packet. This way you can "listen" on just a single port and your code would parse the header and do the right thing.

In the example code using HTONS(0) does not connect (UDP is connectionless) it merely says create a new UDP socket with the destination port of 0 (in the context of that code). The UDP socket on the WiShield does not become "active" until the call to uip_udp_bind() - which tells the uIP stack that you want it to pay attention to incoming data on the port that you give it - 12344 in this case.

If your strategy is to have the WiShield differentiate which button sent the data based upon the source port then I'd rethink things (unless you have the ability to specify both the source and destination ports). I would opt for adding a small header to the packet payload (for instance a single byte that identifies which button it came from).

Greg

[Renasis]

Greg,

Thanks for the info, see my comments in brackets below. The problem I am having is once the Wishield establishes a connection with a pc source port I unable to connect to the wishield with another source port. The destination port to the Wishield is correct and unchanged on each send. I attached some images from wishark and udp send program to explain further. The UDP send program can be found at http://www.codeproject.com/KB/IP/UDP_Send_Receive.aspx. Hopefully this explains what I am trying to do. Any help you could provide would be appreciated.

If your C# library is changing the destination port on you (not the source port) then I'd take a look at the API to make sure that it is being used correctly or toss it as it is doing the wrong thing. [No, it is not. It is sending to the correct destination port, but the source port is changing]

If you want each button to send to a different port on the WiShield then you will need to tell the WiShield to "listen" on two ports (destination ports) and have each button's code send to the appropriate destination port. A simpler approach would be to include a small header in the packet payload that describes what button (or functionality) sent the packet. This way you can "listen" on just a single port and your code would parse the header and do the right thing. [I understand, but this is not what I want to do.]

In the example code using HTONS(0) does not connect (UDP is connectionless) it merely says create a new UDP socket with the destination port of 0 (in the context of that code). The UDP socket on the WiShield does not become "active" until the call to uip_udp_bind() - which tells the uIP stack that you want it to pay attention to incoming data on the port that you give it - 12344 in this case. [OK, I understand now]

If your strategy is to have the WiShield differentiate which button sent the data based upon the source port then I'd rethink things (unless you have the ability to specify both the source and destination ports). I would opt for adding a small header to the packet payload (for instance a single byte that identifies which button it came from). [No, this is not what I am looking to do.]

[GregEigsti]

If you want more than 1 UDP port active on the WiShield try increasing the default value of UIP_CONF_MAX_CONNECTIONS (in uip-conf.h) from the default of 1 to however many you want (2 I presume). I have not tried this so I cannot guarantee that it will work - but it should

Greg

[Renasis]

Greg,

Thanks for the suggestion. I gave it try, but I couldn't get it to work, same results. Any other ideas?

Thanks,

-ren

[GregEigsti]

Any other ideas?

You are not going to like this... But I'd just use the one UDP port and add a different header value for each button and then have the WiShield receive code inspect the header value to know which action to take.

I have never tried multiple "listen" ports on the WiShield; though my inspection of the WiShield code makes me think it should work. All of my apps (that need to do so) utilize the packet header method that I described.

Sorry, don't know what to tell you.
Greg

[GregEigsti]

Just tried it and it worked for me; received data on two UDP ports. It was not reliable - but neither was using one port; am using an old PPC PowerBook and a real quick copy/paste python script to send the UDP data. UDP has been way more reliable for me in the past so I suspect that it has something to do with the PPC PowerBook or the quick and dirty py script. But I did get it to work and it was at least as reliable as using a single port.

EDIT - tried it on the MacBook Pro (i386) and used a bit of C code to send UDP packets. All worked very well and reliably and the Arduino code was able to differentiate between what port received the packet. Unfortunately the MBP took a dive just after I was done and all of the source is on it. <rant>Gotta get it in to get the bad NVidia graphics crap fixed. Bad Nvidia for delivering compromised parts then lying about it. Good Apple for uncovering NVidia's lies and fixing for free.</rant>

Greg

[Renasis]

Greg,

Wow, you got it to work. I must have something wrong with my sketch or a setting in the configuration file. Could you post your sketch and uip_conf.h file? You were working on a 386? Now that is something that you don't hear everyday.

Thanks,

-ren