UDP -> TCP, lastempfindlicher?



  • 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.


Anmelden zum Antworten