Ich brauche einen TCP-option (ioctl) zum senden von Daten sofort
Ich habe eine ungewöhnliche situation: ich bin mit einem Linux-system in einer integrierten Lage (Intel box, derzeit mit einem 2.6.20-kernel.) die für die Kommunikation mit einem embedded system mit einer teilweise gebrochen TCP-Implementierung. Als nahe als ich kann sagen, gerade jetzt Sie erwarten, dass jede Nachricht von uns kommen in eine separate Ethernet-frame! Sie scheinen Probleme zu haben, wenn Nachrichten aufgeteilt sind über Ethernet-frames.
Sind wir auf dem lokalen Netzwerk mit dem Gerät, und es gibt keine Router zwischen uns (nur ein Schalter).
Sind wir natürlich versuchen, Sie zu zwingen, zu beheben Ihr system, aber das kann nicht am Ende als machbar.
Habe ich bereits TCP_NODELAY auf meine Steckdosen (habe ich eine Verbindung zu Ihnen), aber das hilft nur, wenn ich nicht versuchen, zu senden mehr als eine Nachricht gleichzeitig. Wenn ich mehrere ausgehende Nachrichten in einer Zeile, die diese Nachrichten neigen dazu, am Ende in ein oder zwei Ethernet-frames, die Ursachen der Probleme auf dem anderen system.
Kann ich generell das problem vermeiden, indem mit Hilfe eines Timers zu vermeiden, senden von Nachrichten zu nahe zusammen, aber offensichtlich Grenzen unserer Durchsatz. Weiter, wenn ich wieder Zeit nach unten zu niedrig, ich das Risiko von Netzwerk-Staus halten-Paket sendet und damit zu enden, dass mehr als eine meiner Nachrichten in der gleichen Paket.
Gibt es eine Möglichkeit, dass ich sagen kann, ob der Fahrer die Daten in der Warteschlange oder nicht? Gibt es eine Möglichkeit, ich kann erzwingen, dass die Treiber zum senden von unabhängigen schreiben, Anrufe in der independent transport layer-Pakete? Ich habe einen Blick durch die Buchse(7) und tcp(7) - man-Seiten und ich habe nichts gefunden. Es mag sein, dass ich nicht weiß, was ich Suche.
Offensichtlich, UDP wäre eine Möglichkeit, aber wieder, ich glaube nicht, dass wir machen können, das andere Ende nichts ändern viel an dieser Stelle.
Jede Hilfe sehr dankbar.
Du musst angemeldet sein, um einen Kommentar abzugeben.
IIUC, setzen der TCP_NODELAY-option sollte den Inhalt aller Pakete (z.B. tcp.c implementiert die Einstellung NODELAY mit einem Aufruf tcp_push_pending_frames). Also, wenn Sie setzen der socket-option nach jedem senden aufrufen, sollten Sie bekommen, was Sie wollen.
Können Sie nicht umgehen, ein problem, es sei denn, Sie sind sicher, was das problem ist.
Wenn Sie getan haben, den newbie Fehler anzunehmen, dass recv() erhält genau eine Nachricht, dann sehe ich keinen Weg, das zu lösen es vollständig auf. Senden Sie nur eine Nachricht pro Ethernet-frame ist eine Sache, aber wenn mehrere Ethernet-frames eintreffen, bevor der Empfänger recv() aufruft, es werden immer noch mehrere Nachrichten in einem Aufruf.
Überlastung des Netzwerks macht es praktisch unmöglich zu verhindern, dass diese (bei Einhaltung der anständigen Durchsatz), auch wenn Sie kann Ihnen sagen, wie oft Sie call recv().
Vielleicht, TCP_NODELAY gesetzt und stellen Sie Ihren MTU niedrig genug, so dass es bei den meisten 1 message pro frame? Oh, und fügen Sie "dont-fragment" - flag auf ausgehende Pakete
Haben Sie versucht, die öffnung eines neuen socket für jede Nachricht und schließen Sie es sofort? Die Gemeinkosten werden kann, widerlich,aber dies sollte begrenzen Ihre Nachrichten.
In der worst-case-Szenario könnte man eine Ebene tiefer gehen (raw sockets), wo haben Sie eine bessere Kontrolle über die gesendeten Pakete, aber dann müsste man sich mit allen Feinheiten des TCP.
Vielleicht könnten Sie versuchen, indem Sie den tcp-stack in low-latency-Modus:
Sollte zugunsten emitting Pakete so schnell wie möglich über die Verknüpfung von Daten. Lesen Sie den Mann auf tcp(7) für weitere Informationen.