Set UDP Source Port on Send 1

[jrl237]

I'm attempting to communicate with an existing server system that uses UDP to receive commands and return responses.

The server listens on a single port. It expects to reply back to the sending IP on the UDP source port the packet was sent from.

I can easily send it data using something like this:

sckServer.SendTo(bData, epServer)

where sckServer is a socket and epServer is an EndPoint containing the IP address and UDP port of the server.

I cannot find a way to set the sending (source) UDP port. It appears VB selects a random source port when sending. I don't know what this port will be, so I can't listen for the server reply.

Any ideas how to set the UDP source port on a socket send? Is there a better way to do this?

I can't change the server end of things, so I'm stuck making the client end work.

Any help would be greatly appreciated.

 

[Sorwen]

You should be specifying the port in the connection. It would be helpful if you posted your code.

-I hate Microsoft!
-Forever and always forward.
-My kingdom for a edit button!

 

[jrl237]

I think I've found a solution. I still can't set the outgoing source port, but I can query it once a connection has been made, and it seems to use the same source port for subsequent connections.

For posterity, here's the code I'm using:

Dim ServerIP As IPAddress = IPAddress.Parse("10.1.1.1")
Dim ipServer As New IPEndPoint(ServerIP, 1234)
Dim epServer As EndPoint = CType(ipServer, EndPoint)
Dim sockServer As New Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp)

sockServer.Connect(epServer)

Dim ipTemp As IPEndPoint = CType(sockServer.LocalEndPoint, IPEndPoint)

Dim iListen as Integer = ipTemp.Port

At this point, iListen should have the source port the datagram was sent on (not to.) It does appear this is a randomly assigned port above 1024.

 

[Sorwen]

My bad, I misunderstood part of what you were saying. What is your program talking to on the other end? Generally there should be some documentation as to how whatever it is assigns ports. Any...not sure how to put this...real program or equipment isn't going to randomly assign ports. They would understand that ports can often be blocked. Anything that just randomly looks for an open port seems a little sketchy to me.

-I hate Microsoft!
-Forever and always forward.
-My kingdom for a edit button!

 

[jrl237]

It's talking to a PBX. The PBX is set to listen on an assigned port, but it responds to the source port of the sender. It doesn't assign this port. It just reads it out of the UDP packet header.

If you're using sockets (or UDPClient AFAIK) you set the destination port, but VB or the .NET framework, (or maybe even the IP stack) picks the source port. It's not exactly random, as I've seen sequential runs on occassion. But it doesn't appear to be configurable.

 

[Sorwen]

It's talking to a PBX. The PBX is set to listen on an assigned port, but it responds to the source port of the sender. It doesn't assign this port. It just reads it out of the UDP packet header.

If you're using sockets (or UDPClient AFAIK) you set the destination port, but VB or the .NET framework, (or maybe even the IP stack) picks the source port. It's not exactly random, as I've seen sequential runs on occassion. But it doesn't appear to be configurable.

Ah. I thought you were saying it the other way around.

Instead of using an EndPoint and SendTo try using Connect and Send. Every time I've used it with connect the port has always been the same for sending/receiving.


P.S. First keep in mind networking isn't one of my strengths. I was reading up a bit and it looks like with the way you are using the socket it does that on purpose. If you don't set a default host through the connect method and use the SendTo you can have the socket talk with any number of hosts at once. The EndPoint specifying where it sending and the return port. I sounds like it randomly assigns the return port (not sure if it is per EndPoint or SendTo) to reduce the chance of conflicts. That was more implied than stated though so it is just a guess.

Maybe someone with more vb & networking will say.

-I hate Microsoft!
-Forever and always forward.
-My kingdom for a edit button!

 

[Sorwen]

Actually thinking about it from what it said it would have to be for each EndPoint. So the return port should only change each time you create a new EndPoint. Maybe.

-I hate Microsoft!
-Forever and always forward.
-My kingdom for a edit button!

 

[Borvik]

think I've found a solution. I still can't set the outgoing source port, but I can query it once a connection has been made, and it seems to use the same source port for subsequent connections.

For posterity, here's the code I'm using:

Dim ServerIP As IPAddress = IPAddress.Parse("10.1.1.1")
Dim ipServer As New IPEndPoint(ServerIP, 1234)
Dim epServer As EndPoint = CType(ipServer, EndPoint)
Dim sockServer As New Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp)

sockServer.Connect(epServer)

Dim ipTemp As IPEndPoint = CType(sockServer.LocalEndPoint, IPEndPoint)

Dim iListen as Integer = ipTemp.Port

At this point, iListen should have the source port the datagram was sent on (not to.) It does appear this is a randomly assigned port above 1024.

Just so you know - when using the Connect method you are no longer using UDP - that is TCP.

What you want is possible with the Bind method. The Bind method binds the local endpoint (see

http://msdn.microsoft.com/en-us/library/system.net.sockets.socket.bind(VS.71).aspx).

I do not know if this method would work setting the local endpoint with UDP - it is always something you could try though.

Hope that helps you out.

 

[jrl237]

Thanks Borvik. That's exactly what I need.

I greatly appreciate your post.

 

[Sorwen]

Just so you know - when using the Connect method you are no longer using UDP - that is TCP.

VS2k5 and up at least that statement isn't correct. It may default to TCP if you use just a socket (and don't specify), but you can set a socket to use UDP or if you use UDPClinet. Both ways use the same connect method and force it to use UDP not TCP.

That is cool about the IPEndPoint.

-I hate Microsoft!
-Forever and always forward.
-My kingdom for a edit button!

 

[Borvik]

Ah - well that's interesting - I didn't know you could call Connect for a connectionless protocol.

Thanks for that tidbit Sorwen.

 

[Sorwen]

You are just creating the link between your system and the remote system. Connect is just a word it uses for a common understanding. It is essentially the same thing as creating the EndPoint and using a sendto. Except the end point is set for the life of the "connection" and can only be changed with a disconnect and a new connect called. That isn't quite the right explanation because it is what your program thinks of as the life of the connection and not an actual open connection between both ends. I don't know enough to explain what actual steps it might be taking with each individual protocol.

The one thing I have seen is that when I sent data between a client and listener I made was that it returned data on the same port (UDP or TCP). For all I know I could have actually been doing something wrong (or by accident) and it just worked out that way. I could only say it had worked for me. I didn't really have a project to fully test everything it was just more of could I do it and how by passing a little data back and forth.

I'm not quite sure I'm explaining any of this right. Networking isn't my forte. The Bind method you showed definitely seems to be the better way to go since he wouldn't have to worry about making a bunch of changes to his code and it would behave more like what UDP is intended to be used for.

-I hate Microsoft!
-Forever and always forward.
-My kingdom for a edit button!