Twisted Python:多播服务器无法按预期工作

时间:2012-07-28 06:01:50

标签: python twisted multicast

我正在尝试使用twisted python的多播协议。这是一个简单的例子:

我创建了两个服务器,监听224.0.0.1和224.0.0.2,如下所示:

from twisted.internet.protocol import DatagramProtocol
from twisted.internet import reactor
from twisted.application.internet import MulticastServer

class MulticastServerUDP(DatagramProtocol):
    def __init__ (self, group, name):
        self.group = group
        self.name = name
    def startProtocol(self):
        print '%s Started Listening' % self.group
        # Join a specific multicast group, which is the IP we will respond to
        self.transport.joinGroup(self.group)

    def datagramReceived(self, datagram, address):
        print "%s Received:"%self.name + repr(datagram) + repr(address)


reactor.listenMulticast(10222, MulticastServerUDP('224.0.0.1', 'SERVER1'), listenMultiple = True)
reactor.listenMulticast(10222, MulticastServerUDP('224.0.0.1', 'SERVER2'), listenMultiple = True)

reactor.run()

然后我运行此代码发送“HELLO”:

import socket

MCAST_GRP = '224.0.0.1'
MCAST_PORT = 10222

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
sock.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_TTL, 2)
sock.sendto("HELLO", (MCAST_GRP, MCAST_PORT))

结果令人困惑。有几种情况:

- 当我将所有组IP和MCAST_GRP设置为224.0.0.1时,两个服务器都收到了消息(预期) - 当我将发送脚本中的服务器组IP到224.0.0.1和MCAST_GRP设置为224.0.0.2(或者与224.0.0.1不同)时,两个服务器都没有收到消息(预期)

- 当我将一台服务器的组IP设置为224.0.0.1而另一台设置为224.0.0.2时,会发生奇怪的事情。当我将MCAST_GRP设置为224.0.0.1或224.0.0.2时,我预计两台服务器中只有一台接收该消息。结果是BOTH服务器收到了消息。我不确定发生了什么。有人可以解释一下吗?

注意:我在同一台机器上运行它们。

SL

2 个答案:

答案 0 :(得分:2)

确实有点棘手。 你必须这样写:

reactor.listenMulticast(
    10222, 
    MulticastServerUDP('224.0.0.1', 'SERVER1'),
    listenMultiple=True,
    interface='224.0.0.1'
)

reactor.listenMulticast(
    10222, 
    MulticastServerUDP('224.0.0.2', 'SERVER2'),
    listenMultiple=True,
    interface='224.0.0.2'
)

之前我遇到过同样的问题。我不得不看看来源找到它。 但我解决了它,因为我在C网络编程方面的背景。

答案 1 :(得分:1)

多播是古怪的,多播的平台(Linux,Windows,OS X等)实现甚至更加复杂。

Twisted只是反映了平台的多播行为,所以这只是一个与Twisted相关的问题。真的,这是一个多播问题和一个平台问题。

对于发生的事情,这是一个稍微受过教育的猜测。

通过让主机订阅地址来实现多播。当主机上运行的程序加入一个组(例如224.0.0.1)时,主机在本地记录这个并进行一些网络操作(IGMP)来告诉附近的主机(可能是通过路由器,但我模糊了该部分的详细信息)它现在对该组的消息感兴趣。

在多播创建者的理想世界中,该订阅一直在互联网上传播。这是必要的,以便每当互联网上任何地方的任何人向该组发送消息时,无论哪个路由器获得它,它都可以将其传递给已订阅该组的所有主机。这应该比广播更有效,因为只有订阅的主机才需要传递给它们的消息。由于路由器正在跟踪订阅,因此他们可以跳过向没有订阅主机的链路发送流量。

在真实世界中,多播订阅通常不会传播到很远的地方(例如,它们到达第一个路由器,可能是运行房屋局域网的路由器,然后停在那里)。

因此,似乎关于理想宇宙的所有信息都与此场景无关。然而!我怀疑大多数实现组播的人对第一部分的思考真的非常困难,并且在他们完成实现时已经非常累了。

一旦多播组的消息实际到达主机,主机就需要将其传递给实际对其感兴趣的程序。在这里,我怀疑,实施者太累了,无法做正确的事情。相反,他们做了各种懒惰,简单的事情(取决于你的平台)。例如,他们中的一些人刚刚访问了订阅多播组并将消息传递给他们的系统上的每个开放套接字。

在其他平台上,您有时会发现单个多播消息不止一次传递到单个侦听多播套接字。当然,根本没有提供多播消息的流行问题。

享受多播土地上的古怪时光!

相关问题