如何诊断我们的Java IP多播应用程序? [英] How can I diagnose our java IP multicast application?

查看:240
本文介绍了如何诊断我们的Java IP多播应用程序?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

出于某种原因,我运行的每个组播示例(计算机运行OpenSUSE Linux)都可以。客户都只是静静地坐着。我如何找出阻止/忽略多播的原因?

For some reason, every multicast example I run (the computer runs OpenSUSE Linux) will work. The clients all just sit silently. How do I figure out why the multicast is being blocked/ignored?

一些例子:

http://www.roseindia.net/java/example/java/net/udp/UDPMulticastServer.java

http://docs.oracle .com / javase / tutorial / networking / datagrams / broadcasting.html
(使用这些文件:)
http://docs.oracle.com/javase/tutorial/networking/datagrams/examples/MulticastServer.java
http: //docs.oracle.com/javase/tutorial/networking/datagrams/examples/MulticastServerThread.java
http://docs.oracle.com/javase/tutorial/networking/datagrams/examples/MulticastClient.java
http://docs.oracle.com /javase/tutorial/networking/datagrams/examples/one-liners.txt

http://docs.oracle.com/javase/tutorial/networking/datagrams/broadcasting.html (uses these files:) http://docs.oracle.com/javase/tutorial/networking/datagrams/examples/MulticastServer.java http://docs.oracle.com/javase/tutorial/networking/datagrams/examples/MulticastServerThread.java http://docs.oracle.com/javase/tutorial/networking/datagrams/examples/MulticastClient.java http://docs.oracle.com/javase/tutorial/networking/datagrams/examples/one-liners.txt

推荐答案

在排除IP组播故障时,有一些很大的问题 - 您可以采取哪些措施来确定这是主机问题,软件问题还是网络问题:

When troubleshooting IP multicast, there are some big-picture things you can do to isolate whether this is a host issue, software issue, or network issue:


  • 步骤1:确保接收方在正确的接口上发送IGMP组连接。在接收者的接口上查找组播源的流量。

  • 步骤2:确保服务器正在通过正确的接口向正确的组播组发送流量

  • 步骤3:执行类似 ping 的I​​P多播测试(使用linux的 socat 工具)

  • Step 1: Ensure the receiver is sending IGMP group joins on the correct interface. Look for the multicast source's traffic on the receiver's interface.
  • Step 2: Ensure the server is sending traffic on the proper multicast group out the correct interface
  • Step 3: Perform something like a ping test for IP multicast (using linux's socat tool)

每一步的详情概述如下......

The details for each step are outlined below...

首先,确保linux多播接收器正确地宣传他们的组成员报告;请记住,多播中的很多东西都是从单播转发的。例如,多播要求您发送包含要接收的多播组的IGMP加入数据包。

First, ensure that the linux multicast receivers are correctly advertising their group membership reports; keep in mind that a lot of things in multicast work backwards from unicast. For instance, multicasting requires that you send an IGMP join packet that contains the multicast group you want to receive.

使用 tcpdump tshark 来检查有问题的接口......在下面的例子中,我有一台机器在 192.168.12.238 宣布(通过 igmp )它希望从 239.255.0.1接收多播流量

Use tcpdump or tshark to examine the interface in question... In the example below, I have a machine on 192.168.12.238 that is announcing (via igmp) that it wants to receive multicast traffic from 239.255.0.1

[mpenning@Finger ~]$ sudo tshark -n -V -i eth0 igmp
Running as user "root" and group "root". This could be dangerous.
Capturing on eth0
Frame 1 (54 bytes on wire, 54 bytes captured)
    Arrival Time: Dec  6, 2011 09:08:45.156782000
    ... >snip< ...
Internet Protocol, Src: 192.168.12.238 (192.168.12.238), Dst: 224.0.0.22 (224.0.0.22)
    Version: 4
    Header length: 24 bytes
    Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)
        1100 00.. = Differentiated Services Codepoint: Class Selector 6 (0x30)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 40
    Identification: 0x0000 (0)
    Flags: 0x02 (Don't Fragment)
        0.. = Reserved bit: Not Set
        .1. = Don't fragment: Set
        ..0 = More fragments: Not Set
    Fragment offset: 0
    Time to live: 1
    Protocol: IGMP (0x02)
    Header checksum: 0x3663 [correct]
        [Good: True]
        [Bad : False]
    Source: 192.168.12.238 (192.168.12.238)
    Destination: 224.0.0.22 (224.0.0.22)
    Options: (4 bytes)
        Router Alert: Every router examines packet
Internet Group Management Protocol
    [IGMP Version: 3]
    Type: Membership Report (0x22)
    Header checksum: 0xe9fd [correct]
    Num Group Records: 1
    Group Record : 239.255.0.1  Change To Exclude Mode
        Record Type: Change To Exclude Mode (4)
        Aux Data Len: 0
        Num Src: 0
        Multicast Address: 239.255.0.1 (239.255.0.1)

^C1 packet captured

现在检查并查看组播源的流量是否到达此接口(我假设我t是eth0,在下面):

Now check and see whether the multicast source's traffic is getting to this interface (I'm assuming it was eth0, below):

sudo tshark -n -i eth0 ip and host 239.255.0.1

如果您看到流量发送到正确的组播组,则直接进入步骤3;否则转到步骤2.

If you see traffic sent to the proper multicast group, then proceed directly to Step 3; otherwise go to Step 2.

接下来确保您的多播服务器正在将流量发送到正确的小组。在下面的示例中,我运行一个命令来嗅探 eth0 ,以查找发送到 239.255.0.1 的流量。

Next ensure that your multicast server is sending the traffic to the correct group. In the example below, I run a command to sniff eth0 for traffic sent to 239.255.0.1.

[mpenning@hotcoffee Models]$ sudo tshark -n -i eth0 ip and host 239.255.0.1

1.466991 192.168.12.236 -> 239.255.0.1  UDP Source port: 11111  Destination port: 11111

如果组播源正在向在第2步中右键组,您在步骤1中看到IGMP组加入,并且步骤1未在组播接收器的界面上看到流量,然后联系您的网络管理员以解决此问题。

If the multicast source is sending traffic to the right group here in Step 2, you saw IGMP group joins in Step 1, and Step 1 did not see traffic at the multicast receiver's interface, then contact your network administrators about this problem.

假设一切正常,并且您仍然需要进行酸性测试,以防您的多播接收器软件以某种方式丢弃从IP堆栈接收的多播。确保您的计算机上安装了 socat 并执行以下操作...

Assuming all that works, and you still want an acid test in case your multicast receiver software is somehow discarding multicast it receives from the IP stack... make sure you have socat installed on your machine and do the following...

在多播发送方(服务器),使用此命令将测试多播数据包发送到 239.255.0.1

On the multicast sender (server), use this command to send test multicast packets to 239.255.0.1:

perl -e '$ii=0; while (1) { print "hi number $ii\n"; $ii++; }' | socat - UDP-SENDTO:239.255.0.1:11111,sp=11111

在多播接收器(客户端)上),使用此命令侦听在 eth0 上发送到 239.255.0.1 的测试多播数据包:

On the multicast receiver (client), use this command to listen to test multicast packets sent to 239.255.0.1 on eth0:

socat - UDP-DATAGRAM:239.255.0.1:11111,bind=:11111,ip-add-membership=239.255.0.1:eth0

假设您的网络管理员允许多播 239.255.0.1 ,你会在多播接收者的终端窗口看到很多这样的流量:

Assuming your network administrators are allowing multicast on 239.255.0.1, you will see a lot of traffic like this in the multicast receiver's terminal window:

hi number 212289
hi number 212290
hi number 212291
hi number 212292
hi number 212293
hi number 212294
hi number 212295
hi number 212296
hi number 212297
hi number 212298

注意:不要试试这个已在网络上使用的多播组地址。

NOTE: do not try this with a multicast group address that is already in production use on your network.

如果步骤1,图2和图3显示通过您的网络发送和接收多播流量,然后打电话给软件开发人员并告诉他们您认为应用程序存在问题并解释您到目前为止所采取的步骤。

If steps 1, 2, and 3 reveal that multicast traffic is being sent and received through your network, then call up the software developer and tell them you think there is a problem with the application and explain the steps you have taken so far.

如果步骤1,2或3不起作用,请重新配置您的软件/主机/网络,直到它们为止。警告,IP网络中的多播比IP单播更难实现3倍。

If steps 1, 2, or 3 do not work, reconfigure your software / hosts / network until they do. Warning, multicast in IP networks is 3x harder to implement correctly than IP unicast.

祝你好运......

Best of luck to you...

这篇关于如何诊断我们的Java IP多播应用程序?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆