Can't send a udp packet to the local PC?
Sin Jeong-hun
ProtocolType.Udp);
//ServerPoint = new IPEndPoint(IPAddress.Parse("127.0.0.1"),
50000); //<---(1) This has no effect.
ServerPoint = new IPEndPoint(IPAddress.Parse("100.1.2.3"),
50000); //<---(2) This works.
int sent = s.SendTo(new byte[100], ServerPoint);
Debug.WriteLine("===> " + sent + " bytes sent");
After two hours of head scratching, I'm finally asking here. I tried
to test a simple UDP server / client applications on my PC. But I
couldn't send a UDP packet to the local (the same pc where the sending
application is on) pc. If I set the ServerPoint with line (1), even
though SendTo returns 100, I cannot see an outgoing UDP packet on the
Ethereal. Only if I change the destination address to another PC like
line (2), does a UDP packet go out. What is wrong with the code above?
Of course I don't think there is a limitation as two local
applications cannot communicate with UDP, since I did that once with
Java a few years ago.
I tried UdpClient (of course I didn't use the same port for both
client/server), my public IP address instead of 127.0.0.1,
IPAddress.Loopback, Dns.GetHostByName("localhost"), etc but the result
was the same.
Thank you for any hint.
Sin Jeong-hun
It looks like that when the destination address is the same PC, the
UDP stack doesn't pass down the packet to the IP layer, but handles it
on its own. For some complicated reason, I want it to pass down the
packet to the physical Ethernet interface so that Ethereal can catch
the frame. I searched MSDN and found that there is a socket option
named UseLookback. I tried to set it false, but an exception has
occurred, and I cannot find any example to do this on Google.
The followings are what I have tried.
s.SetSocketOption(SocketOptionLevel.IP, SocketOptionName.UseLoopback,
0);
s.SetSocketOption(SocketOptionLevel.IP, SocketOptionName.UseLoopback,
false);
s.SetSocketOption(SocketOptionLevel.Udp, SocketOptionName.UseLoopback,
0);
s.SetSocketOption(SocketOptionLevel.Udp, SocketOptionName.UseLoopback,
false);
s.SetSocketOption(SocketOptionLevel.Socket,
SocketOptionName.UseLoopback, 0);
s.SetSocketOption(SocketOptionLevel.Socket,
SocketOptionName.UseLoopback, false);
All of them throws an exception saying something like invalid option
level or invalid value.
Peter Duniho
wrote:
> It looks like that when the destination address is the same PC, the
> UDP stack doesn't pass down the packet to the IP layer, but handles it
> on its own.
Yes, that makes sense. When you send locally, the network stack can tell
right away that there's no available socket to receive the data, so you
get the error. Sending to some arbitrary IP address, it can't so it
_seems_ to work, even if there's nothing around to receive it.
> For some complicated reason, I want it to pass down the
> packet to the physical Ethernet interface so that Ethereal can catch
> the frame. I searched MSDN and found that there is a socket option
> named UseLookback. I tried to set it false, but an exception has
> occurred, and I cannot find any example to do this on Google.
I believe that the exception is because even though .NET defines the
enumeration value, the Microsoft network stack doesn't actually support
the option. See here for a documentation page that seems to support my
impression:
http://msdn.microsoft.com/en-us/library/ms740532.aspx
Note that even if the option was supported, I don't think it's something
you'd find useful anyway. The default value would be "false", and so
setting it to "false" isn't going to change anything. The option is used
when you want to _force_ the use of loopback, not when you want to inhibit
it.
Have you tried sending explicitly to a local IP address for your PC? I
suspect you'd run into the same problem you have with the loopback
address, but it's worth a try anyway. I have to admit, I think that
unless you can somehow specify an address you know is _not_ a valid local
address, the network stack is going to be getting in your way. Typically,
one would want it to fail as early as possible in the transmission
sequence, to provide the most complete information. So I'm not sure that
the TCP/IP implementation is designed with your use case in mind.
Whatever it is you're actually trying to accomplish here, you may have to
do it a different way.
Pete