Hi,
ich habe im Moment ein etwas exotischeres Problem: ich will zwei Prozesse auf den selben UDP-Port binden. Um genau zu sein: es ist eine Multicast-Anwendung, die mit sich selbst reden können soll.
setsockopt mit SO_REUSEADDR scheint nicht zu helfen - beim bind kommt trotzdem ein Fehler, dass der Port schon benutzt wird.
Kennt jemand eine Lösung?
(wen es interessiert, Sourcen sind hier: svn co https://silmor.de/svn/misc/mcvlan)
Konrad
Hi Konrad,
On Mon, Sep 07, 2009 at 10:16:06 +0200, Konrad Rosenbaum wrote:
ich habe im Moment ein etwas exotischeres Problem: ich will zwei Prozesse auf den selben UDP-Port binden. Um genau zu sein: es ist eine Multicast-Anwendung, die mit sich selbst reden koennen soll.
setsockopt mit SO_REUSEADDR scheint nicht zu helfen - beim bind kommt trotzdem ein Fehler, dass der Port schon benutzt wird.
Disclaimer: Ich habe wenig Ahnung von Multicasting. QEMU kann unter anderem Multicasting benutzen, um mehrere QEMU-Instanzen (auch lokal auf dem gleichen Host) miteinander zu vernetzen. Mit netstat sehe ich, dass sich zwei QEMUs an die gleiche Multicast-Adresse und an den gleichen UDP-Port binden. Dabei wird anscheinend die Socket-Option IP_MULTICAST_LOOP benutzt, um lokal generierten Traffic auch wieder lokal zu sehen.
Gruss, Chris
On Monday 07 September 2009 11:07:36 Christian Perle wrote:
On Mon, Sep 07, 2009 at 10:16:06 +0200, Konrad Rosenbaum wrote:
setsockopt mit SO_REUSEADDR scheint nicht zu helfen - beim bind kommt trotzdem ein Fehler, dass der Port schon benutzt wird.
Disclaimer: Ich habe wenig Ahnung von Multicasting.
Ist nicht schlimm.
QEMU kann unter anderem Multicasting benutzen, um mehrere QEMU-Instanzen (auch lokal auf dem gleichen Host) miteinander zu vernetzen. Mit netstat sehe ich, dass sich zwei QEMUs an die gleiche Multicast-Adresse und an den gleichen UDP-Port binden. Dabei wird anscheinend die Socket-Option IP_MULTICAST_LOOP benutzt, um lokal generierten Traffic auch wieder lokal zu sehen.
Das hat mir zumindest gezeigt, dass es gehen muss.
Die Lösung ist ganz einfach: wenn man eine IPv6 Socket öffnet nimmt diese zunächst mal an, dass sie im Notfall auch IPv4 bedienen können muss. SO_REUSEADDR wirkt anscheinend aber nur auf das native Socket-Protokoll. Man muss also zusätzlich die Socket überzeugen, dass sie nur IPv6 macht (setsockopt mit IPPROTO_IPV6,IPV6_V6ONLY).
Konrad
lug-dd@mailman.schlittermann.de
-
Christian Perle -
Konrad Rosenbaum