http://msdn.microsoft.com/en-us/library/ms817942.aspx
http://msdn.microsoft.com/en-us/library/ms740476.aspx

bei TCP solltest du den Nagle's Algorithm ausdrehen.

eine andere geschwindigkeitsbremse des ist das: http://support.microsoft.com/kb/328890
(auf 1 stellen)

Mach dir keine Gedanken über Traffic, das ist heutzutage zu vernachlässigen.

das stimmt gerade bei games nicht.

hustbaer schrieb:

bei TCP solltest du den Nagle's Algorithm ausdrehen.

eine andere geschwindigkeitsbremse des ist das: http://support.microsoft.com/kb/328890
(auf 1 stellen)

Delayed-Ack wirkt sich AFAIK nur im Zusammenspiel mit Nagle's Algorithm verzögernd aus.
Wenn auf beiden Seiten Nagle's deaktiviert ist, kann Delayed-Ack ruhig eingeschaltet bleiben.
Da man Nagle's auf Socket-Ebene kontrollieren kann, würde ich sagen ist das der bessere Weg.

lagg0r schrieb:

UDP für schnelle Positionswechsel verwenden. Richtig programmiert ruckelt da nix, außer ihr LAGt.

Es ruckelt schnell mal was, wenn man kein dead reckoning verwendet.

Wenn auf beiden Seiten Nagle's deaktiviert ist, kann Delayed-Ack ruhig eingeschaltet bleiben.

nee, das sind zwei verschiedene dinge. aber wenn 2 windoofs-kisten untereinander kommunizieren, wahrscheinlich sowieso egal. nur wenn einer auf das ACK angewiesen ist, bevor er das nächste paket sendet (ein pufferloses TCP z.b.), dann muss 'delayed ack' ausgeschaltet werden, ansonsten haste pro paket eine wartezeit von 0.2s

hustbaer schrieb:

Wenn auf beiden Seiten Nagle's deaktiviert ist, kann Delayed-Ack ruhig eingeschaltet bleiben.

nee, das sind zwei verschiedene dinge. aber wenn 2 windoofs-kisten untereinander kommunizieren, wahrscheinlich sowieso egal. nur wenn einer auf das ACK angewiesen ist, bevor er das nächste paket sendet (ein pufferloses TCP z.b.), dann muss 'delayed ack' ausgeschaltet werden, ansonsten haste pro paket eine wartezeit von 0.2s

Ja das sind zwei verschiedene Dinge, aber sie spielen zusammen.
Wenn Delayed-ACK eingeschaltet ist, dann kommen ACKs später an als sonst. Im schlimmsten Fall eben 200ms später.
Wenn AKCs nun aber 200ms später ankommen, dann kann es sein, dass Nagle's eben diese 200ms wartet, bis er das nächste Paket verschickt.

Nagle's Algorithm:

if there is new data to send
  if the window size >= MSS and available data is >= MSS
    send complete MSS segment now
  else
    if there is unconfirmed data still in the pipe     <-------- HIER PROBLEM wenn der andere Delayed ACK verwendet
      enqueue data in the buffer until an acknowledge is received
    else
      send data immediately
    end if
  end if
end if

Das Problem ergibt sich dann, wenn ein Flusswechsel stattfindet. Beispiel wo A ein Stück Daten welches aus drei Paketen besteht an B senden will, und dann auf eine Antwort von B wartet.

* A sendet ein Paket an B. Erstes Paket geht sofort raus.
* B empfängt, und schickt ein ACK.
* A sendet ein zweites Paket. Das geht raus sobald das ACK von B empfangen wurde (sagen wir das geht halbwegs schnell).
* B empfängt das 2. Paket, sendet aber kein ACK, weil Delayed ACK.
* A will ein drittes Paket senden, das wird aber vom Nagle gepuffert (weil "unconfirmed data still in the pipe" - A wartet ja noch auf das 2. ACK von
* A wartet auf die Antwort von B. B hat aber noch garnicht alle Daten erhalten, weil A noch auf das 2. ACK wartet -> Delay, bis irgendwo irgendwelche Timeouts ablaufen.

----

Delayed-ACK stellt für sich genommen kein Problem dar, führt also nicht zu irgendwelchen "lags". Nur in Kombination mit Nagle's ergibt sich das oben skizzierte Verhalten, und deswegen dreht man Nagle's ab, wenn man will das Daten schnell ankommen.

ein pufferloses TCP z.b.

WTF? Ist das sowas wie ein Auto ohne Motor?

ein pufferloses TCP z.b.

WTF? Ist das sowas wie ein Auto ohne Motor?

so ähnlich. TCPs in mikrocontrollern mit sehr wenig RAM haben keinen ausgangs-FIFO (dieses z.b. http://sourceforge.net/projects/opentcp/ )sondern arbeiten nach dem 'ping-pong prinzip', d.h. das nächste paket wird erst geschickt, wenn das ACK für das vorherige paket eingetrudelt ist. lässt sich die windows-kiste nun 0.2s zeit mit dem ACK, kannste dir vorstellen, wie langsam das ganze ist.

Naja sowas muss man denke ich nicht berücksichtigen

zumindest hat's mit der frage des OP nichts mehr zu tun. ansonsten wird TCP gern genommen, um embedded systeme mit den pc-kisten kommunizieren zu lassen.

hustbaer schrieb:

Ein Puffer für ein oder zwei Pakete würde da ja bereits ausreichen...

ja, für ein paket. dann kann man schnell zwei TCP segmente hintereinander senden (sofern die summe beider paketlängen die window-size des empfängers nicht überschreitet), um sofort ein ACK zu bekommen.