Receiving Broadcast message from socket

Receiving Broadcasts

Compete Application code can be found from here.

 

The most obvious place to begin testing the operation of the broadcast server, is on the same host as the server. This is shown in the following session output:

Output

@rhel54x64

[root@rhel54x64 socket]# ./udp-broadcast-client 192.168.0.255:9097

DJIA 10304.73 +1.43

NASDAQ 2761.19 -0.56

S&P 500 1283.31 +0.00

TSE 300 6895.82 +0.10

DJIA 10304.73 +1.43

NASDAQ 2761.19 -0.56

S&P 500 1283.31 +0.00

TSE 300 6896.35 +0.63

The session demonstrates that indeed, the broadcasts are being received from the server. Now it's time to try the client program on another host and see broadcasts being received over a physical

network.

Receiving Broadcasts from a Remote Host

Another host named slug is used in this demonstration, with an IP address of 192.168.0.2. Starting a copy of the client program on that host looks like this:

Output

@rhel55x86

[root@rhel55x86 socket]# ./udp-broadcast-client 192.168.0.255:9097

DJIA 10309.80 +6.50

NASDAQ 2767.29 +5.54

S&P 500 1286.06 +2.75

TSE 300 6897.75 +2.03

DJIA 10309.80 +6.50

NASDAQ 2767.29 +5.54

S&P 500 1286.06 +2.75

TSE 300 6897.67 +1.95

DJIA 10313.18 +9.88

NASDAQ 2767.29 +5.54

S&P 500 1286.06 +2.75

TSE 300 6897.67 +1.95

Here, it is demonstrated on host slug that broadcasts were indeed being received over the Ethernet link between these two hosts. The values are different in this output because it was captured much later than the earlier session shown. However, if you were to establish clients that ran on the local and remote hosts at the same time, you would be able to verify that their content was in full agreement.

Troubleshooting Hints

If you fail to achieve similar results on your own personal network, then a large number of things could be involved in the problem. It is not the intention of this book to describe aspects of network administration or design. Nor will this book be a treatise on network troubleshooting. The following simple tips are offered in the hope that it might prove to be useful as a starting point in diagnosis.

If the problem exists over a simple network of your own construction and there is little or no network traffic on it, you might be able to just look at the hub. Many mini-hubs, for example, offer LED indicators that provide indication of packet traffic for the corresponding ports involved. The server program presented should cause a flicker to occur approximately every four seconds when a broadcast occurs. Failure to see this suggests that the broadcast is not occurring.

Another approach is to use the tcpdump command, which is now part of most Linux distributions today. An example of tcpdump(8) output is shown as follows while the server was broadcasting:

Output

@rhel55x86

# tcpdump udp port 9097

tcpdump: listening on eth0

21:04:43.967482 pepper.ve3wwg.org.1032 > 192.168.0.255.9097: udp 96

21:04:47.977482 pepper.ve3wwg.org.1032 > 192.168.0.255.9097: udp 96

21:04:51.987482 pepper.ve3wwg.org.1032 > 192.168.0.255.9097: udp 96

The command-line arguments used cause only the UDP packets on port 9097 to be displayed. The sample output includes three packet summaries that were displayed. More information about tcpdump(8) can be accessed by reading its manual page.

These are but two very simple methods of checking for broadcast packets. Frequently, however, these simple techniques will be sufficient for the programmer.