2010-07-08 13 views
10

Ich habe eine Java-Reader-Anwendung, die von einem Multicast-Socket auf einer Linux-64-Bit-Plattform (2.6.18) liest. Die Socketgröße wurde auf 2 MB festgelegt. Wenn der Leser nicht schnell genug lesen kann, "läuft der Socket über", d. H. Pakete werden aus dem Puffer fallen gelassen.Wie läuft ein Linux-Socket-Puffer über?

Was ich gerne wissen würde ist, wie der Linux-Kernel Pakete aus dem Socket-Puffer löscht. Ich nehme an, dass der Socket-Puffer selbst ein FIFO-Puffer ist. Wenn es aber voll ist, was passiert? Wird das nächste Paket verworfen (und der Pufferinhalt ändert sich nicht)? Oder ersetzt das neue Paket ein altes Paket im Puffer? Wenn ja, welches Paket (das älteste ?, das jüngste ?, ein zufällig ausgewähltes Paket?)?

Danke für jede Einsicht.

Antwort

8

Wenn der Puffer voll ist, werden eingehende Pakete verworfen. Pakete, die sich bereits im Puffer befinden, werden nicht geändert oder ersetzt.

+0

Danke. Haben Sie eine Verknüpfung/Quelle, die diese Aussage unterstützt? – AtomicJake

+0

@AtomicJake: Dies ist eine Standardpraxis des Netzwerkdesigns. Oder: Was kann OS noch tun? IIRC Wenn der Socket-Puffer voll ist TCP-Stack setzt die Fenstergröße auf 0. Alle eingehenden Pakete in diesem Zustand würden einfach als ungültig betrachtet (nicht zum Fenster passen) und somit verworfen. Lesen Sie die RFC793, suchen Sie nach dem "Empfangsfenster". – Dummy00001

+0

Sie sind richtig für TCP, aber ich fragte speziell nach einem Multicast-UDP-Lese-Socket. Soweit ich weiß, wird jedes eingehende Paket vom Netzwerk in einen unabhängigen Socket-Puffer kopiert (ein Puffer pro Lesegerät). Die Steckdose wird somit von jedem Leser in einem anderen Tempo geleert. Unter Linux, wenn ein Puffer voll ist, wird ein neues Paket einfach verworfen - oder (wie im Ringpuffer) überschreibt der älteste Eintrag? Ich würde annehmen, dass beide Implementierungen legal sind. – AtomicJake

2

Nur eine Ergänzung zu der Antwort von JS Bangs.

Dies ist nicht der einzige Ort im Netzwerkstapel, an dem Pakete gelöscht werden können. Der Socket-Empfangspuffer ist hoch in der Hierarchie und spezifisch für den Benutzer-Socket. Ein anderer Ort näher an der Hardware (zumindest in Linux) ist die Warteschlange zwischen dem Gerätetreiber und dem NET_RX Softirq (siehe netif_rx().) Diese Tropfen tragen zur RX-DRP Spalte im netstat -i Ausgang bei.

+0

Danke. Ich habe mit 'sar' festgestellt, dass ich tatsächlich Pakete auf dem Socket-Puffer verliere, der von der Anwendung gelesen wird. Ich kann die Zähler sehen, wenn Pakete fallengelassen werden, weil die Anwendung zu langsam zum Lesen ist. – AtomicJake