UDP -> TCP, lastempfindlicher?
-
HEHO, hatte hier vor langer zeit mal n thema zum wechsel von udp zu tcp(im gleichen quellcode) erstellt, habe das jetzt nach langer zeit tatsächlich durchgeführt und nun ein problem festgestellt:
zwar steht die verbindung, jedoch scheint sie durch übermäßig häufigen gebrauch nur kurze zeit stabil zu sein
folgende situation:
Gelenke eines Roboters schicken an einen leitrechenr via can nachrichten. Ein teil dieser nachrichten wird auf einen nebenstehenden pc verschickt.
Das verschicken via CAN(und direkt folgend via tcp) wird(wenn ich nicht täusche) alle 10 ms durchgeführt, die alte udp verbindung lief dabei stabil(bei der selben last) die tcp-verbindung hingegen nicht oOIst TCP da anfälliger? prinzipiell hat das ganze ja ne art handshake damit keine daten verloren gehen, kann das also sein?
in Kurzfassung:
Kann zu häufig ausgeführtes send() mit recht kleinen Datenmengen zum Zusammenbrechen der Verbindung bei TCP führen(im Gegensatz zu udp wo es keine verbindungen gibt)?
Wie könnte ich damit umgehen?
-
Dieser Thread wurde von Moderator/in SeppJ aus dem Forum C (C89, C99 und C11) in das Forum Rund um die Programmierung verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
TCP bricht nicht bei kleinen sends zusammen. TCP garantiert allerdings, dass entweder die Daten korrekt in korrekter Reihenfolge ankommen, oder TCP sagt "Error". Das bedeutet es gibt Bestätigungspakete. Telnet-Programme, die nur ein Byte per TCP schicken, brauchen 3 Pakete pro Byte, eins zum Byte senden, eins für die Bestätigung dass das Byte auch angekommen ist und eins zum Bestätigen der Bestätigung. Es kann also sein, dass die Leitung die 3fache Last nicht mit macht.
Weiterhin ist TCP schlecht bei schlechten Leitungen und unabhängigen Daten. Beispielsweise könnte eine Gelenkbewegung aus 15 einzelnen Paketen für 15 einzelne Gelenke bestehen. Wenn das erste Paket verloren geht werden die 14 angekommenen zurück gehalten, damit die Reihenfolge korrekt bleibt. Bei Gelenken, Streaming, Onlinespielen und generell allem was mit unvollständigen Teildaten etwas anfangen kann ist das schlecht. Wenn du allerdings auf korrekte Daten in richtiger Reihenfolge angewiesen bist wirst du nichts effizienteres als TCP mit UDP zusammen bauen (= Bestätigungspakete senden + Reihenfolge korrigieren) können.
BTW wie äußert sich denn das Zusammenbrechen der TCP-Verbindung? Sockets melden Fehler? Welchen Fehler? Hast du mal per Wireshark oder so nachgesehen was da passiert? Zumindest auf der PC-Seite.
-
Super, vielen dank für die infos.
Ich kann dir das gerade nicht sagen, da ich erst montag wieder an den roboter komme(uni).
Ich schau mir dass dann mal an und melde mich
Zur not muss ich wohl nen puffer einbauen, wobei ich dann wieder mir nicht vertrauten code ändern muss(was auf dem leitrechner eine qual ist)
-
Namenloser324 schrieb:
Super, vielen dank für die infos.
Ich kann dir das gerade nicht sagen, da ich erst montag wieder an den roboter komme(uni).
Ich schau mir dass dann mal an und melde mich
Zur not muss ich wohl nen puffer einbauen, wobei ich dann wieder mir nicht vertrauten code ändern muss(was auf dem leitrechner eine qual ist)wobei mir gerade einfällt, dass jaschon ein puffer existiert. Die Nachricht eines Gelenks(die dann tatsächlich via WLAN versendet wird) besteht aus ca. 20-30 Byte, wobei aber eine Nachricht in einen buffer geschrieben wird und dann versendet wird was da drin ist, naja wie gesagt, ich muss mir das morgen genauer anschauen.
-
So guten morgen.
Sitze jetzt wieder dabei und es scheint als wäre nicht der leitrechner schuld sondern der empfänger pc. Das Programm(leider nicht von mir, sonst wüsste ich schneller was vorliegt) welches den empfang managed scheint irgendwo nen ungültigen pointer zu erzeugen und stürzt ab. Daraufhin werden die gelenkdaten auf dem roboter in den buffer auf dem leitrechner gepackt welcher aber wegen des abstürzens des empfängers nicht mehr geleert wird -> er quillt über und alles zerbricht.(fragt mich nicht wieso das so programmiert worden ist) Davor läuft es für ~10 sekunden stabil.
Ich seh mir das jetzt an, falls was ist melde ich mich.
-
SOoo, es scheint wohl definitiv an wxWidget gelegen zu haben, welches zur Programmierung der Visualisierung der Gelenkdaten genutzt wird.
Die Ausgabe der Gelenkdaten in einem Textfenster hat scheinbar auf Dauer das Programm um seinen Lebenswillen gebracht läuft das Tool jetzt doch ohne Probleme.
Muss ich mal nachforschen ob ich was zu häufer Benutzung von Textfeldern in wxWidget finde.
Danke an nwp3
-
wichtiger als das bestaetigen ist dass tcp auch load balancing macht. da die ip packete nicht durchgaengig von sender zu empfaenger geschickt werden, sondern zig knoten im netzt passieren, gibt es unmengen an buffern und verschiedene bandbreiten, es kann sein dass ein server mit 10GBit/s schicken kann, der empfaenger ein 3g modem hat und dann kann der versender nicht flockig 1MB/s schicken und die 'bleiben dann irgendwo', weil der provider nicht 100MB cache pro user anlegen will. deswegen gibt es verschiedene algorithmen die versuchen abzuschaetzen wie schnell verschickt werden darf, natuerlich faengt sowas klein an, hast du also stossweise packete die du schickst, statt gleichmaessig, wird der algorithm jedesmal bei kleinen bandbreiten anfangen und dann hast du weit weniger durchsatz als durchgaengig TCP packete zu schicken, selbst wenn darin nichts steht.
ich weiss ja nicht wie dein robo-server arbeitet, aber das koennte bei tcp gegenueber udp ein nachteil sein.
-
na ja. tcp macht kein load balancing. wenn load balancing passiert, dann ist es egal ob tcp oder udp. sollte das dann nicht flow basiert passieren, hat jemand seine geraetschaften schlecht konfiguriert.
der rest ist auch fraglich, da es fuer den udp burst offensichtlich gereicht hat. ansonsten tcp verbindung offen halten, dann bleiben's die sliding windows auch.
-
tcp schrieb:
na ja. tcp macht kein load balancing. wenn load balancing passiert, dann ist es egal ob tcp oder udp. sollte das dann nicht flow basiert passieren, hat jemand seine geraetschaften schlecht konfiguriert.
du kannst nach "tcp congestion control" suchen um deine wissensluecke aufzufuellen
z.b.
http://en.wikibooks.org/wiki/Communication_Networks/TCP_and_UDP_Protocols
-
danke nein. load balancing ist das verteilen von traffic auf verschiedene pfade und hat nichts mit congestion control zu tun. wie willst du mir was ueber meine wissenluecken erzaehlen, wenn du nicht einmal mit den begrifflichkeiten vertraut bist? also bitte erst seepferdchen machen bevor du mir unwissen unterstellst
btw, wenn ich in deinem link nach "bal" suche, habe ich schon keinen treffer. hat anscheinend nix mit tcp zu tun. hab ich ja bereits geschrieben.
-
tcp schrieb:
danke nein. load balancing ist das verteilen von traffic auf verschiedene pfade und hat nichts mit congestion control zu tun.
load balancing ist im englischen allgemein die verteilung von last, auch traffic erzeugt eine last. du versuchst die geschwindigkeit zu maximieren, wie es häufig üblich ist bei load balancing, dabei ziel ist die fehlerquote die durch zuviel traffic entsteht mit starvation die durch zuwenig traffic entsteht so auszugleichen, dass die beste transferrate auszulotet wird.
das ist auch das problem bei tcp, wenn eine transportschicht nicht zuverlässig ist, selbst wenn sie mehr bandbreite zulässt, wird die verbindung als überlastet angesehen und fast alle algorithmen drosseln.
btw, wenn ich in deinem link nach "bal" suche, habe ich schon keinen treffer. hat anscheinend nix mit tcp zu tun. hab ich ja bereits geschrieben.
diese transferleistung zu erbringen ist eine persönliche herausforderung, versuche sie zu meistern.
-
meisterer schrieb:
tcp schrieb:
danke nein. load balancing ist das verteilen von traffic auf verschiedene pfade und hat nichts mit congestion control zu tun.
load balancing ist im englischen allgemein die verteilung von last
du schreibst es doch selber. verteilung von last, parallelisierung. dein beschriebenes problem ist rein serieller natur.
meisterer schrieb:
btw, wenn ich in deinem link nach "bal" suche, habe ich schon keinen treffer. hat anscheinend nix mit tcp zu tun. hab ich ja bereits geschrieben.
diese transferleistung zu erbringen ist eine persönliche herausforderung, versuche sie zu meistern.
load-balancing ist ein feststehender begriff in der telekommunikationsbranche; da kann ich dir leider keinen spielraum fuer interpretationen einraeumen.
-
meisterer schrieb:
...
schon ok, ich brauche keinen verteidiger ;), er hat sicher dem thread starter signifikant geholfen mit seinen beitraegen die rausstellen wo er nicht meiner meinung ist. mehr beitraege werden den thread nicht weiterfuehren ;), bin dann raus hier.
btw. lustige zeichen, proxy? man darf zu seiner meinung stehen... und feige annonym zu sein
-
[quote="rapso"]...wo er nicht meiner meinung ist./quote]
da hast du meine einwaende missverstanden. die industrie schafft standards und vokabular, damit bei solchen angelegenheiten eine meinung irrelevant ist.
-
rapso schrieb:
[...]mit seinen beitraegen die rausstellen wo er nicht meiner meinung ist.
Ich verstehe das Problem nicht so recht. Load Balancing und Congestion Control sind wirklich nicht das selbe, da hat er schon recht.
Aus dem Kontext konnte man schon halbwegs schlieszen, was du wohl meinst, aber tcps Beitraege sind technisch durchaus korrekt.