Warum sollte ich MSG_CONFIRM verwenden oder nicht verwenden?
Lesezeit: 6 Minuten
qdii
Ich kenne mich mit BSD-Sockets aus und blättere durch die Manpage von sendtoIch stieß in MSG_CONFIRM Flagge, die mir im Moment ziemlich rätselhaft ist.
Die Beschreibung sagt:
Teilen Sie der Verbindungsschicht mit, dass der Vorwärtsfortschritt stattgefunden hat: Sie haben eine erfolgreiche Antwort von der anderen Seite erhalten. Wenn die Verbindungsschicht dies nicht bekommt, wird sie den Nachbarn regelmäßig neu prüfen (z. B. über ein Unicast-ARP). Nur gültig für SOCK_DGRAM- und SOCK_RAW-Sockets und derzeit nur für IPv4 und IPv6 implementiert.
Nach einem kurzen Blick auf die Manpage von arpIch verstehe, dass etwas markiert wird MSG_CONFIRM verhindert, dass die ARP-Zuordnung MAC-Adresse ↔ IP-Adresse des Remote-Computers als veraltet betrachtet wird.
Jetzt bin ich verwirrt, weil ich keinen Grund sehe, warum ich es tun sollte nicht gesagt, und warum haben sie das nicht direkt in der Bibliothek durchgesetzt. Warum wird von der Anwendungsschicht erwartet, dass sie sich mit allem befasst, was dort unten auf der Verbindungsschicht passiert?
Also habe ich etwas verpasst? Wann sollte ich es einstellen oder nicht?
Sie sollten das Flag nur setzen, wenn das von Ihnen gesendete Datagramm eine direkte Antwort auf ein Datagramm ist, das Sie gerade von demselben Peer erhalten haben.
Wenn Sie eine erste Anfrage senden oder ein Datagramm als Antwort auf ein anderes Ereignis (wie eine Benutzereingabe oder eine Zeitüberschreitung) senden, sollten Sie dies tun nicht setze die MSG_CONFIRM Flagge.
Was sollte der Standardwert für die Erstanfrage sein, wenn nicht MSG_CONFIRM?
– Lichter aus
30. Oktober 2018 um 19:24 Uhr
@bakalolo: Wenn Sie keine Flags haben, die Sie in einem Anruf setzen können sendto()übergeben Sie einfach 0 als die flags Parameter.
– Café
31. Oktober 2018 um 3:01 Uhr
Ein Quellenverweis für die Informationen in dieser Antwort wäre schön zu haben.
– Armali
7. November 2021 um 17:18 Uhr
Eine Quelle für MSG_CONFIRM: linux.die.net/man/2/sendto. Diese Antwort enthält jedoch mehr Informationen und bessere Informationen als diese Referenz. Ich wünschte nur, wir hätten eine Referenz, woher diese Antwort die Informationen hat.
– Gabriel Staples
1. April 2022 um 19:25 Uhr
Der Grund, es nicht zu senden, ist, falls sich die MAC-Adresse für die IP im Laufe der Zeit ändert. Wenn Sie Ihrem System ständig sagen, dass es nicht nachsehen soll, sendet es weiterhin an denselben MAC, auch wenn die IP-Adresse nicht mehr vorhanden ist.
Es scheint der Fall zu sein, dass das Senden eine ganz besondere Situation erfordert, in der Sie Dinge über den Empfänger Ihrer Nachrichten garantieren können. Der Overhead einer periodischen ARP-Anfrage ist sehr gering, daher sind die Vorteile äußerst begrenzt.
Ach … die kryptische Manpage für sendto() macht jetzt mehr Sinn!: MSG_CONFIRM (Since Linux 2.3.15) Tell the link layer that forward progress happened: you got a successful reply from the other side. If the link layer doesn't get this it will regularly reprobe the neighbor (e.g., via a unicast ARP). Only valid on SOCK_DGRAM and SOCK_RAW sockets and currently only implemented for IPv4 and IPv6. See arp(7) for details. Also NICHT einschließlich der MSG_CONFIRM Flag weist das zugrunde liegende Netzwerk an, die MAC-Adresse regelmäßig für diese IP zu überprüfen.
– Gabriel Staples
1. April 2022 um 19:27 Uhr
@GabrielStaples, es ist ein bisschen seltsam für mich, dass es so klingt, als könnte ein User-Space-Prozess (mit SOCK_DGRAM) das Verhalten der Verbindungsschicht direkt beeinflussen. Ich würde das mit SOCK_RAW verstehen, weil Sie Superuser-Rechte haben müssen, um das auszuführen. Die Verbindungsschicht wird jedoch von allen Prozessen gemeinsam genutzt. (Ich kann mich sehr irren, aber so lese ich es)
– xaxxon
2. April 2022 um 21:48 Uhr
@xaxxon: Ich nehme an, dass die bestimmtes Datagramm mit geschickt MSG_CONFIRM wird den Kernel nicht dazu veranlassen, die Zieladresse erneut zu prüfen. Alle Datagramme, die an dasselbe Ziel gesendet werden (durch denselben oder andere Prozesse) ohneMSG_CONFIRMWille Triggern Sie den Kernel, um die Zieladresse erneut zu prüfen (wenn der Nachbar-Cache-Eintrag veraltet ist). Es gibt also kein Problem mit Privilegien; ein Prozess kann nicht verwendet werden MSG_CONFIRM um zu verhindern, dass andere Prozesse den Kernel dazu veranlassen, Zieladressen erneut zu prüfen; sie kann nur für sich selbst auf diesen Dienst verzichten.
– Matt Whitlock
10. Dezember 2022 um 4:28 Uhr
Gabriel Staples
Dies ist mein Versuch, dies zu verstehen, nachdem ich die anderen beiden Antworten hier gelesen habe.
Wenn Sie sich fragen, wann Sie die verwenden sollen MSG_CONFIRM Im Wesentlichen weist es die zugrunde liegende ARP-Netzwerkschicht nur an, den MAC der Empfänger-IP NICHT regelmäßig zu überprüfen (was die ARP-Hardware-MAC-Adresse-zu-IP-Adresse-Zuordnung aktualisieren würde), weil wir uns auf die IP verlassen an das wir senden, ist das Gerät, für das wir es halten, da diese Nachricht gesendet wird direkte Antwort auf eine Nachricht, die wir gerade erhalten von ihnen! Mit anderen Worten, lassen Sie im Zweifelsfall OUT weg MSG_CONFIRM Flagge. Setzen Sie es NUR ein, wenn die Nachricht, die wir senden, eine direkte Antwort auf eine empfangene Nachricht ist, und deshalb möchten wir die Netzwerkeffizienz ein wenig erhöhen, indem wir den MAC NICHT regelmäßig erneut überprüfen, auf die Gefahr hin, dass sich der Ziel-MAC ändern könnte falsch und kein Einzelgänger stimmt mit der IP-Adresse für das Gerät überein, von dem wir glauben, dass wir diese Nachricht senden!
Vorteile der Verwendung MSG_CONFIRM:
Es erhöht die Effizienz des Netzwerks, da ARP NICHT erneut nach dem MAC der Zieladresse suchen muss.
Nachteile oder Risiken der Verwendung MSG_CONFIRM:
Dies kann bedeuten, dass, wenn das alte Gerät im Netzwerk abfällt und ein neues Zielgerät im Netzwerk mit derselben Zieladresse wie das alte, aber mit einem anderen Hardware-MAC auftaucht, wir es nicht wissen, weil MSG_CONFIRM sagt ARP nicht um den MAC dieser IP-Adresse erneut zu prüfen.
Wenn MSG_CONFIRM kann verwendet werden:
Wenn unsere ausgehende Nachricht eine direkte Antwort auf eine Nachricht ist, die wir gerade von diesem Gerät erhalten haben, sind wir sicher, dass ihr MAC immer noch korrekt ist.
MSG_CONFIRM in diesem Fall kann man sich das als eine „Bestätigungs“-Nachricht an den Absender vorstellen, dass wir seine vorherige Nachricht erhalten haben.
Teilen Sie der Verbindungsschicht mit, dass der Vorwärtsfortschritt stattgefunden hat: Sie haben eine erfolgreiche Antwort von der anderen Seite erhalten.Wenn die Verbindungsschicht dies nicht erhält, wird sie den Nachbarn regelmäßig erneut testen (z. B. über ein Unicast-ARP).. Nur gültig am SOCK_DGRAM Und SOCK_RAW Sockets und derzeit nur für implementiert IPv4 Und IPv6. Sehen arp(7) für Details.
Meine Faustregel lautet also: benutze es einfach nicht. Es hat wenig Nutzen. Aber wenn Sie es verwenden möchten, verwenden Sie es nur
Um (über eine UDP-Nachricht) direkt an den Absender einer UDP-Nachricht zu antworten, die gerade über empfangen wurde recvfrom()oder gleichwertig, oder
In eingebetteten Gerätenetzwerken, in denen Sie feste (statische) MAC-Adressen, IP-Adressen und ARP-MAC-zu-IP-Zuordnung haben und alles sorgfältig manuell steuern, Und Kümmern Sie sich nicht um den winzigen Gewinn an Netzwerkeffizienz, der durch das Deaktivieren von ARP-Prüfungen erzielt wird.
14435900cookie-checkWarum sollte ich MSG_CONFIRM verwenden oder nicht verwenden?yes
