Jump to content
ChrisChuah

IdUDPClient send packet to Broadcast address. how to avoid getting the data back

Recommended Posts

Hi

Each time i send a packet of data to the broadcast address, the same packet will be received back again.

How can i

1. control the idUDPClient to ignore the packet

2. How to determine the ip address is a broadcast address in the network

 

please advise

 

regards

chris

 

Share this post


Link to post
2 hours ago, ChrisChuah said:

How can i

1. control the idUDPClient to ignore the packet

On some platforms, you might be able to just set the TIdUDPClient.BoundIP property to the IP of the network adapter you are sending broadcasts from.  On other platforms, you might have to resort to using TIdUDPClient.Binding.SetSockOpt(SO_BINDTODEVICE) to bind to a network interface by name instead of IP.  But either way, this should prevent your outgoing network adapter from receiving duplicates of its own broadcasts.

2 hours ago, ChrisChuah said:

2. How to determine the ip address is a broadcast address in the network

Not quite sure I understand what you are asking.

 

If you are asking how to ignore the IP of the broadcaster, then whenever you receive a packet, you are also given the sender's IP (and port).  You can just ignore packets that come from your own IP.

 

If you are asking what a broadcast IP is in general, then it is a network IP that is masked by its subnet mask, and then OR'ed with the inverse of the subnet mask.  So, for example, if you have an IP of 192.168.100.5 and a subnet mask of 255.255.255.0, then the broadcast IP is 192.168.100.255:

 

192.168.100.5 & 255.255.255.0 = 192.168.100.0

~255.255.255.0 = 0.0.0.255

192.168.100.0 | 0.0.0.255 = 192.168.100.255

Share this post


Link to post
9 hours ago, Remy Lebeau said:

On some platforms, you might be able to just set the TIdUDPClient.BoundIP property to the IP of the network adapter you are sending broadcasts from.  On other platforms, you might have to resort to using TIdUDPClient.Binding.SetSockOpt(SO_BINDTODEVICE) to bind to a network interface by name instead of IP.  But either way, this should prevent your outgoing network adapter from receiving duplicates of its own broadcasts.

Not quite sure I understand what you are asking.

 

If you are asking how to ignore the IP of the broadcaster, then whenever you receive a packet, you are also given the sender's IP (and port).  You can just ignore packets that come from your own IP.

 

If you are asking what a broadcast IP is in general, then it is a network IP that is masked by its subnet mask, and then OR'ed with the inverse of the subnet mask.  So, for example, if you have an IP of 192.168.100.5 and a subnet mask of 255.255.255.0, then the broadcast IP is 192.168.100.255:

 

192.168.100.5 & 255.255.255.0 = 192.168.100.0

~255.255.255.0 = 0.0.0.255

192.168.100.0 | 0.0.0.255 = 192.168.100.255

Hi Remy

Yes. As i send a UDP packet to a 192.168.100.255, the IP address that returns to me is also 192.168.100.255 as well as a reply from other servers.

Is there a function to say isBroadcastAddress(aIPAddress: string) that i can use so as to know its a broadcast address?

Does Indy library has such function?

 

regards

chris

 

Share this post


Link to post
14 hours ago, ChrisChuah said:

Yes. As i send a UDP packet to a 192.168.100.255, the IP address that returns to me is also 192.168.100.255

That is not right.  It should be the sender's IP, not the target's IP.  Where are you getting that IP from?

14 hours ago, ChrisChuah said:

Is there a function to say isBroadcastAddress(aIPAddress: string) that i can use so as to know its a broadcast address?

No (and even if there were, the IP alone is not enough, you need the associated subnet mask, too). You would have to calculate the broadcast IP yourself, or on some platforms you can use an API to query it from the network adapter directly.

Share this post


Link to post

that is how network does it's job.
causes of this, this address is called 'broadcast address.
you can simply ignore it if you does need it.
the other way, do not use tcp/ip network protocol at all.
just develop your own protocol so it can work precisely like what you want.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×