Network programming: UDP Clients

[Structural Integrity]

Do clients that use UDP also have to bind their socket for listening? Or can you receive UDP data without binding the socket (like with TCP)?

[MT]

  my $sock = new IO::Socket::INET->new(LocalPort=>5555,Proto=>'udp',LocalAddr=>'localhost');
  while (1) {
    my $data;
    $sock->recv($data,128);
  }

(in other words, yes a udp listener binds to a TSAP the same as a tcp listener does)

[Structural Integrity]

That's not really what I meant...

If you have a client that connects to a server does the client have to be a server to receive data?

When using TCP you use "connect" and a session is started, and you have a two way channel. Both client and server can receive and send data on the same socket.
But with UDP there isn't a "connect", so I was wondering if both parties had to explicitly listen on a certain port by binding the sockets.

[pablissimo]

I was under the impression that to receive UDP packets you have to have some interface to the socket layer in your code; i.e. listen on a given port, so yeah it looks probable.

[Structural Integrity]

Another thing.... errr... can I somehow FORCE a socket to use a certain outgoing port when opening a socket?

Well... my problem is the following.
I'm making this client/server app, but I want to test it on one computer using the localhost address.
So, for both the clients and servers I bound a UDP socket to listen on a port NEAR 4444 (it can be 4444 to 4449).
However, my problem is the following: The server doesn't know on beforehand to which port the client is listening.
So, I thought, when I use the recv function, I can see what the incoming port is, and send it back to that port.... yeh.... well....
NO. The incoming ports are somewhere in the 23000 while I expected them to be 4444-4449.

So, what am I doing wrong? Why doesn't my client socket send it's stuff with the same port as it's listening on?

int mySocket = socket(AF_INET, protocol, 0);

	// make sure nothing bad happened
	if (mySocket == SOCKET_ERROR) {
		printf("Error Opening Socket!\n");
		return -1;
	}
	addr.sin_family = AF_INET;
	addr.sin_port = htons(port);
	addr.sin_addr.s_addr = INADDR_ANY;



	if (protocol == SOCK_STREAM)
	{
		if (connect(mySocket, (sockaddr*)&server, sizeof(server)) == SOCKET_ERROR) {
			printf("Error connecting to server!\n");
		}
	}
	else if (protocol == SOCK_DGRAM)
	{
		for (int i=0; i<5; i++) 
		{
			if (bind(mySocket, (sockaddr*)&addr, sizeof(addr)) != SOCKET_ERROR)
				break;
			port++;
			addr.sin_port = htons(port);
			printf("Bind Failed!\n");

		}
	}

[queball]

If you bind() before connect()ing (or not connecting, if you're just gonna sendto(), but you might connect() anyway) you can choose your local port with sin_port (this works for outgoing and incoming, TCP and UDP).

[queball]

Originally posted by Structural Integrity

NO. The incoming ports are somewhere in the 23000 while I expected them to be 4444-4449.
....

If it helps,
4444=0x115C
0x5C11=23569
You use htons, but that code snippet is incomplete and out of context as far as I can see.

[Structural Integrity]

Originally posted by queball
If it helps,
4444=0x115C
0x5C11=23569
You use htons, but that code snippet is incomplete and out of context as far as I can see.

You're the winner for solving the "odd port prob"...
So my problem is in either the clients receive part or the servers send part....

[Structural Integrity]

OK... I severely messed up with casting some variables.

I have a callback function in my main app that took an unsigned long as parameter to identify the client. I use the same callback method for both UDP and TCP, so the client identification was a tad different.
However, I gave a 14 byte SOCKADDR struct to this function in the case of UDP so the last 10 bytes were dropped. I thought that a long was 8 byte, which would have been enough.

Oh well... solved now... I can send data in both directions with UDP!
\o/

[edit]
Editted the "bits" to "bytes", as pab pointed out
[/edit]

[Structural Integrity]

Originally posted by pablissimo
Long == 32bits innit?

Sorry, I meant bytes.... =/

[pablissimo]

I should have noticed that =(

[W]

You can of course code directly for IP and answer UDP packets on any port, or a combination of ports, of your likeing.

If it's any consolation, I had a hard time grasping the source and destination ports of IP too, before I sat down and studied the ip rfc.

[Gayle29uk]

PEAR network libraries rock my world \o/

I know it's PHP but so what :P

[MT]

I was wondering when W would show up :) IIRC he's the daddy of UDP IPC.