Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

Nox

Supermoderator

Beiträge: 5 272

Beruf: Student

  • Private Nachricht senden

51

17.07.2012, 09:49

Und ich vermute den wenigsten bekannt, aber eine logische Folgerung aus der reliability Forderung. Mit dem gleichen Ansatz kann man glaube ich aber auch bei UDP für schwachfug sorgen, wenn auch nicht zur Totalblockierung. Denn irgendwo müssen die Daten ja gespeichert werden und bei UDP übernehmen das meist irgendwelche programmeigenen Container; keine Empfangsbestätigung -> kein leeren der Container -> bei geeigneter Stimulierung des Servers läuft sein Speicher voll und es knallt.
Die Lösung des Problems ist aber denkbar einfach: Einführung einer maximal tolerierten Pufferobergrenze. In TCP ist das einfache eine Kombination aus non-blocking und SO_SNDBUF. Sollten die Puffer dann jemals volllaufen quitiert send den Aufruf mit einem Fehler und man kann den Client ins Nirvana jagen. Beim recv Aufruf kann man dann entweder das "wouldblock" Ereignis abfangen oder recv einfach mit select kombinieren um vorher zu testen ob es was zum lesen gibt.
Nebenbei empfehle ich je nach Anwendungfall von TCP auch auf den TCP_NODELAY Flag zu achen um ggf das nagle-ack-delay Problem zu umgehen.
PRO Lernkurs "Wie benutze ich eine Doku richtig"!
CONTRA lasst mal die anderen machen!
networklibbenc - Netzwerklibs im Vergleich | syncsys - Netzwerk lib (MMO-ready) | Schleichfahrt Remake | Firegalaxy | Sammelsurium rund um FPGA&Co.