Fwd: Re: Programmieren: Daten im TCP gebuffert?
Jan-Benedict Glaw <jbglaw@lug-owl.de> schrieb am 26.05.04 11:20:44:
On Wed, 2004-05-26 10:03:09 +0200, Christian Weddeling <christian.weddeling@web.de> wrote in message <1065826580@web.de>:
[...die längste Prali^WZeile der Welt:-]
Sorry. Jetzt hoffentlich besser.
Ich habe hier eine Anwendung (Client, Server) geschrieben, die über eine TCP-IP-Socket kommuniziert. Gelegentlich kommt es vor, das ein Datenpacket vom Client an den Server geschickt wird, dort aber nicht vollständig ankommt. Der Rest wird aber erst dann geschickt, wenn wieder ein weiteres Datenpacket geschickt wird. Das kann dann schon mal einige Minuten dauern und bis dahin hängt die Anwendung ziemlich in der Luft
Du solltest wohl select() benutzen, um erstmal zu prüfen, ob denn gelesen werden kann. Kommt zu lange nichts, shutdown() und alles von vorn.
Das mit select() mache ich schon. Sind ja ~50 Verbindungen zu überwachen. Was ist shutdown ()...? Ach so, hm, ich versuch mal TCP_NODELAY. Shutdown zieht erheblichen Implementierungsaufwand nach sich.
Es kann aber auch sein, daß einfach Daten nicht sofort gesendet werden. Da gibt's Verfahren, um mehrere schnell aufeinanderfolgende send()/...-Aufrufe zu kombinieren (Stichwort "Nagle-Algorithmus"). Das kannst Du über TCP_NODELAY ausschalten. Guck' mal, ob's damit besser wird.
Okay, werde ich mal versuchen.
Das nicht unbedingt alle Daten in ein IP-Packet passen, ist mir ja klar, aber wieso bleibt denn aber der Rest stecken?
U.U. wg. Nagle:)
Ich dachte immer, daß Nagle ein paar Millisekunden lang die Daten sammelt und dann weiterschickt. Das es da eine Mengenbregrenzung gibt war mir nicht bekannt. -- Ciao Christian -- Ciao Christian _____________________________________________________________________ Endlich SMS mit Bildern versenden! Das Bild selbst ist dabei gratis, Sie bezahlen lediglich den Versand. http://freemail.web.de/?mc=021195
Teilnehmer (1)
-
Christian Weddeling