473,320 Members | 1,828 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

UDP socket problem - not receiving data form server

I have a UDP socket that sends out a request on a multicast socket and waits
for a response. This client is not listening on a multicast IP but the
local IP. The server (UNIX) responds to the sender's IP. Using debug files
on the server I see the server receive the request from my application on my
machine and I see the server send to the correct IP and port of my machine,
but the ReceiveFrom never returns with any data. If I have a multicast
server running on a windows machine it works fine, just getting data from
the multicast server running on the UNIX machine is giving me problems. I
ran netmon and watched the packet flow. According to netmon the server's
response arrives at my machine with the data in it. Why doesn't the socket
read. This is a blocking ReceiveFrom call. The only difference I can see
is that the Windows multicast server binds using the internal IP and port
while the UNIX server binds using the multicast IP and port. When I run
client apps on the UNIX machines they all receive their data fine from both
windows and UNIX. The difference in the debug is the datagram packet has
the multicast IP as the source IP when coming from a UNIX server and the
server's local IP when coming from the windows server. The destinations
from both servers are the local IPs of the client, be it UNIX client, or
windows client.

What's wrong. I tried binding to the multicast IP on the windows server but
it won't allow it.

Any help would be GREATLY appreciated. I've been pulling my hair out for
over a week on this one.

Thanks in advance,
jim
Nov 16 '05 #1
10 12145
Hi Jim,

I am currently doing research on this issue and I will get back to you as
soon as possible.

Have a nice day.

Regards,

Felix Wang
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

Nov 16 '05 #2
Hi Jim,

Have you tried sending a UDP packet with an internal IP (instead of a
multicast address) as source address from the UNIX server to the Windows
machine? Does "ReceivedFrom" work for that simple test?

Regards,

Felix Wang
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

Nov 16 '05 #3
Hi Jim,

Have you tried sending a UDP packet with an internal IP (instead of a
multicast address) as source address from the UNIX server to the Windows
machine? In other words, this is a plain UDP packet from your UNIX server
to Windows box. Does "ReceiveFrom" work for that simple test?

Regards,

Felix Wang
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

Nov 16 '05 #4
Yes I have and yes it does. I can send and receive normal UDP packets where
the source address in the packet is NOT a multicast IP.

"Felix Wang" <v-*****@online.microsoft.com> wrote in message
news:Yg**************@cpmsftngxa10.phx.gbl...
Hi Jim,

Have you tried sending a UDP packet with an internal IP (instead of a
multicast address) as source address from the UNIX server to the Windows
machine? In other words, this is a plain UDP packet from your UNIX server
to Windows box. Does "ReceiveFrom" work for that simple test?

Regards,

Felix Wang
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

Nov 16 '05 #5
Hi Jim,

Does it happen on a local LAN? Is there any router involved?

Also, I think the following information is also quite important:

1) "ReceiveFrom never returns with any data"
I know that you are using blocking ReceiveFrom call. What is the behavior
here? ReceiveFrom just blocks there? Is there any error message returned?

2) If you also join the windows client into the multicast group? Could it
recieve data?

Assuming that the Unix process is sending data back to the your app using
multicast, you could configure your application to receive multicast
packets, and ensure that you are listening on the same UDP port number that
is used in the Unix multicast session. Assuming the Unix process is using
multicast address 224.100.0.1, and UDP port 9050, if you are using sockets,
your receiver should look like this:
Dim sock as New Socket(AddressFamily.InterNetwork, _
SocketType.Dgram, _
ProtocolType.Udp)
Dim iep as new IPEndPoint(IPAddress.Any, 9050)
sock.Bind(iep)
sock.SetSocketOption(SocketOptionLevel.IP, _
SocketOptionName.AddMembership, _
new
MulticastOption(IPAddress.Parse("224.0.0.1")))
Dim ep as EndPoint = CType(iep, EndPoint)
Dim data(1024) as byte
Dim recv as int16
recv = sock.ReceiveFrom(data, ep)

If you are using UdpClient() objects, your receiver should look like this:
Dim client as New UdpClient(9050)
client.JoinMulticastGroup(IPAddress.Parse("224.100 .0.1"))
Dim iep as new IPEndPoint(IPAddress.Any, 0)
Dim data(1024) as byte
data = client.Receive(iep)

As a side note, if you are sending the multicast packets across a large
network, make sure that any intermediate routers are configured to pass
multicast packets.

From your error description, I know that the server (UNIX) responds to the
sender's IP currently. However, please do a test to see whether joining a
group helps under this situation.

3) Generally speaking, when recieiving data, the source IP address of a
packet is not that impormant. If the destination IP address and post is
right, ReceiveFrom will get the data from the lower layer. Could you please
email us the two netmon logs? (from normal windows server and from a unix
server) We will look into it to see whether there is any useful
information. You can reach me by removing online from my email address here.

Thanks very much.

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

Nov 16 '05 #6
Yes, it happens on the local lan. (I did set the multicast TTL to 16
anyway).

1. Yes, ReceiveFrom just blocks. No error message.

2. No, joining the multicast group does not change the result. I have
already tried this just to see if it would make a difference. Still no data
returned.
The UNIX app is not sending back data using multicasting. The packet is
sent to the client's local IP.
Note: Using netmon on the client PC the packet's destionation address is
the local IP of the PC. The source address is a multicast address.

I understand what you are saying in your code snippet. There are 2 problems
in doing it that way.
1. The server does not send to a multicast address, it send data back to
the sender it received from.
2. If the server sent to the multicast address and there was more than one
client running then the client would receive multiple responses from the
same server. 1 response for each request to the servers made by each
client. This application uses multicasting to allow clients to find all the
servers and not the other way around.

I agree, the source address should not make a difference if the destination
address is correct, but for whatever reason it seems to make a difference.

BTW the UNIX server is running HPUX 11i.

I will run netmon again and send you the capture logs as soon as I get a
chance.

Thanks again,
jim
"Yan-Hong Huang[MSFT]" <yh*****@online.microsoft.com> wrote in message
news:j$*************@cpmsftngxa10.phx.gbl...
Hi Jim,

Does it happen on a local LAN? Is there any router involved?

Also, I think the following information is also quite important:

1) "ReceiveFrom never returns with any data"
I know that you are using blocking ReceiveFrom call. What is the behavior
here? ReceiveFrom just blocks there? Is there any error message returned?

2) If you also join the windows client into the multicast group? Could it
recieve data?

Assuming that the Unix process is sending data back to the your app using
multicast, you could configure your application to receive multicast
packets, and ensure that you are listening on the same UDP port number that is used in the Unix multicast session. Assuming the Unix process is using
multicast address 224.100.0.1, and UDP port 9050, if you are using sockets, your receiver should look like this:
Dim sock as New Socket(AddressFamily.InterNetwork, _
SocketType.Dgram, _
ProtocolType.Udp)
Dim iep as new IPEndPoint(IPAddress.Any, 9050)
sock.Bind(iep)
sock.SetSocketOption(SocketOptionLevel.IP, _
SocketOptionName.AddMembership, _
new
MulticastOption(IPAddress.Parse("224.0.0.1")))
Dim ep as EndPoint = CType(iep, EndPoint)
Dim data(1024) as byte
Dim recv as int16
recv = sock.ReceiveFrom(data, ep)

If you are using UdpClient() objects, your receiver should look like this:
Dim client as New UdpClient(9050)
client.JoinMulticastGroup(IPAddress.Parse("224.100 .0.1"))
Dim iep as new IPEndPoint(IPAddress.Any, 0)
Dim data(1024) as byte
data = client.Receive(iep)

As a side note, if you are sending the multicast packets across a large
network, make sure that any intermediate routers are configured to pass
multicast packets.

From your error description, I know that the server (UNIX) responds to the
sender's IP currently. However, please do a test to see whether joining a
group helps under this situation.

3) Generally speaking, when recieiving data, the source IP address of a
packet is not that impormant. If the destination IP address and post is
right, ReceiveFrom will get the data from the lower layer. Could you please email us the two netmon logs? (from normal windows server and from a unix
server) We will look into it to see whether there is any useful
information. You can reach me by removing online from my email address here.
Thanks very much.

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

Nov 16 '05 #7
Hello Jim,

Thanks very much for the quick response. I have also received your email
and netmon log.

I discussed it quickly with our WinSock product team member. As we all see,
the problem is in the source IP address. In fact, Multicast IP address is
not allowed in the source IP address. This is a violation of the following
RFC: http://www.ietf.org/rfc/rfc1122.txt

- Sending packets with a multicast source address (which is what the unix
server is doing) is a violation of RFC1122 [see 1 below].
1) 3.2.1.3 Addressing: RFC-791 Section 3.2
When a host sends any datagram, the IP source address MUST be one of its
own IP addresses (but not a broadcast or multicast address).

- Discarding such packets on receipt (which is what the windows client is
doing) is in compliance with RFC1122 [see 2 below].
2) 4.1.3.6 Invalid Addresses
A UDP datagram received with an invalid IP source address (e.g., a
broadcast or multicast address) must be discarded by UDP or by the IP layer
(see Section 3.2.1.3).

I think that explains the behavior that you met. Does that answer your
question?

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

Nov 16 '05 #8
Nice job!

--
William Stacey, MVP

Nov 16 '05 #9
Thanks, that's what I thought. There appears to be a bug in HPUX because
you can't bind to the internal address. If you do it discards multicast
packets. I have a support ticket in with HP.

Thanks again,
jim

"Yan-Hong Huang[MSFT]" <yh*****@online.microsoft.com> wrote in message
news:i7**************@cpmsftngxa10.phx.gbl...
Hello Jim,

Thanks very much for the quick response. I have also received your email
and netmon log.

I discussed it quickly with our WinSock product team member. As we all see, the problem is in the source IP address. In fact, Multicast IP address is
not allowed in the source IP address. This is a violation of the following
RFC: http://www.ietf.org/rfc/rfc1122.txt

- Sending packets with a multicast source address (which is what the unix
server is doing) is a violation of RFC1122 [see 1 below].
1) 3.2.1.3 Addressing: RFC-791 Section 3.2
When a host sends any datagram, the IP source address MUST be one of its
own IP addresses (but not a broadcast or multicast address).

- Discarding such packets on receipt (which is what the windows client is
doing) is in compliance with RFC1122 [see 2 below].
2) 4.1.3.6 Invalid Addresses
A UDP datagram received with an invalid IP source address (e.g., a
broadcast or multicast address) must be discarded by UDP or by the IP layer (see Section 3.2.1.3).

I think that explains the behavior that you met. Does that answer your
question?

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

Nov 16 '05 #10
Hello All,

Glad to be of assistance on it. If there is any we can do when you
contacting HP, please feel free to post in the newsgroup.

Enjoy the community. :)

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

Nov 16 '05 #11

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

4
by: flupke | last post by:
Hi, I have a gui (made in wxPython) that enables a user to connect to a server and issue some commands. The problem occurs when i try to disconnect the client. It exits but it doesn't return to...
3
by: Robert A. van Ginkel | last post by:
Hello Fellow Developer, I use the System.Net.Sockets to send/receive data (no tcpclient/tcplistener), I made a receivethread in my wrapper, the receivethread loops/sleeps while waiting for data...
3
by: Robert A. van Ginkel | last post by:
In news:OZ0W9RsdDHA.2432@TK2MSFTNGP10.phx.gbl... I ask the question how I can see if all the data is on the other side of the connection. I got as answer that I should use the blocking property. I...
10
by: feel52 | last post by:
Below you'll find the code i'm working on. It's in a button click routine and hangs after 3 or 4 sometimes 5 loops done, probably in sock.receive(....). Some code was found here( on google i mean)...
4
by: rs | last post by:
how I the client tell the server that the socket is closed? or this there an even that informs the server that the clients socket is close? Oh, I am using vb.net 2003 Thanks
2
by: djc | last post by:
I read a network programming book (based on framework 1.1) which indicated that you should 'never' use the RecieveTimeout or the SendTimeout 'socket options' on TCP sockets or you may loose data. I...
7
by: Ole | last post by:
Hi, I'm going to develop a socket communication between an instrument (running CE 5.0 with Compact Fraework V2) and a PC. As the instrument should only connect to one PC at a time I believe that...
9
by: darthghandi | last post by:
I am trying to create a server application using asynchronous sockets. I run into a problem when I try to connect to my server using a non-.net program. I can establish the connection, and send...
0
by: george585 | last post by:
Hello! I am new to network programming, and understand just basics. Using some sample code, and having read documentation, I managed to create a simple app in C# and VB.NET. The application is...
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.