Problem: TCP Pakete werden verschluckt



  • Ja ich hab ein kleines problemchen was mich schon 2 tage beschäfftigt

    Ich habe ein Server zur Verfügung bekommen ,der einen tcp Stream entgegen nimmt und dann weiter verarbeitet.

    Ich soll jetzt den Server mit Daten beschiessen. Hab ein Client geschrieben, der funkst auch. Aber wenn ich mal 10 bis 20 TCP Stream schicke verschluckt der Server es oder ab und zu schmeisst er mir auch ne fehler meldung: "connection reset by peer". Da ich an den Server nix ändern darf wollte ich fragen ob man testen kann ob die packete angekommen sind.

    Ich benutze für das versenden den Linux befehl "send()" Der Rückgabewert von Send zeigt mir immer genau die Länge an(als ob alles Prima wäre) aber es kommt nicht alles an.

    Ich habs auch schon mit pausen und so probiert, aber pausen sind halt sehr unsicher,weil es ja das Grundproblem nicht lösst.

    Ich vermute der grund liegt an einen vollen Speicher oder so (aber nur ne vermutung).

    Ich bin für jede Vermutung, Schubser oder Link sehr Dankbar.

    Ach ja:
    Betriebssystem: Linux (Version irgendwas)
    Programmiersprache: Schönes altes C



  • Gsst schrieb:

    Ich soll jetzt den Server mit Daten beschiessen. Hab ein Client geschrieben, der funkst auch. Aber wenn ich mal 10 bis 20 TCP Stream schicke verschluckt der Server es oder ab und zu schmeisst er mir auch ne fehler meldung: "connection reset by peer". Da ich an den Server nix ändern darf wollte ich fragen ob man testen kann ob die packete angekommen sind.

    dieses 'connection reset by peer' bedeutet, dass der andere die verbindung gewaltsam gekappt hat (er hat ein RST geschickt). möglicherweise ist der server(code) fehlerhaft (server stürzt ab und startet dann wieder). ein speicherproblem halte ich eher für unwahrscheinlich, würd's aber nicht ausschliessen.



  • Mag sein, aber wie glaub ich schon erwähnt habe, darf ich nichts am server ändern (ist halt ne wichtige unantastbare software).
    Was mich nur interessieren würde ob irgendjemand, eine möglichkeit kennt zu testen ob der vom Client gesendeten Daten überhaupt ankommen. Ausserdem bezweifel das es unbedingt am Server liegt, denn wenn ich nur ein mal ein 200 byte Stream übersendete kommt auch nix an. es klappt nur bei kleinen Datenströmen oder wenn es viele kleine packete (mit grossen pausen) versendete.



  • Hmm ich bin ja nicht tatenlos und habe deshalb herausgefunden das wenn ich was nach dem zweitenmal senden will komischer weise gespeichert wird und im nächsten Sendeversuch es noch drin steht.

    Das könnte eine von vielen Möglichkeiten sein.

    Tja es gibt zwar den Befehl "fflush" in ansi-uralt C aber hat irgendjemand ne ahnung wie man diesen befehl auf einen "tcp-Buffer" anwenden kann?



  • Gsst schrieb:

    Mag sein, aber wie glaub ich schon erwähnt habe, darf ich nichts am server ändern (ist halt ne wichtige unantastbare software).

    das ist schlecht.
    naja, angenommen in deinem client ist kein logischer fehler: kannste es mit sniffen versuchen (ethereal, tcpdump, etc. gibt's ja auch für linux). dann siehst eventuell, warum dir der server ein RST sendet (wenn er denn richtig funktionieren sollte).

    ein tcp sollte RST senden wenn:
    - irgendwas anderes kam als erwartet (z.b. datenpaket ohne vorherigem verbindungsaufbau oder die gegenstelle hat irgendwelche flags falsch gesetzt, duplicated SYN usw.)
    - verbindungsanfrage auf einem port ankam, der nicht im 'listen' state ist
    - irgendwas schlimmes passiert ist, was einen sofortigen verbindungsabbruch erfordert (z.b. anwendung ist abgestürzt, in dem fall sorgt das betriebsystem für's RST. die anwendung kann es ja nicht mehr)

    btw: falls der server wirklich vermackelt ist, du aber nix ändern darfst, dann musste eben deinen client so bauen, dass der server damit klarkommt...



  • Hmm neue Vermutung:

    Der server nimmt nämlich die nachrichten entgegen, schickt diese an einem hardware gerät (auch per tcp), bekommt vom hardware gerät einen stream zurück und sendet diesen an meinen Client
    Da die ganze "rumsenderei" sehr lange dauert und ich den Server wirklich 3 bis 4 nachrichten hintereinander sende, dass der Server irgendwann ein speicherproblem bekommt und der server dann halt ein rst-signal sendet.

    das kling für mich noch logisch ABER mein Dummy Server(grad selbst geschrieben in Java-hmm was für eine schöne sprache aber zurück zum thema) der die daten auch entgegennehmen kann, kackt(verschluckt tcp-streams) auch ab. Hmm ausserdem erklärt das immer noch nicht warum ab einer Länge von ca. 135 Byte garnix mehr ankommmt. also wenn ich ein paket losschicke was grösser als 135 byte werte enthält läuft erhalten beide Server(also Dummy sowohl als auch realer Server) garnix mehr



  • Gsst schrieb:

    Da die ganze "rumsenderei" sehr lange dauert und ich den Server wirklich 3 bis 4 nachrichten hintereinander sende, dass der Server irgendwann ein speicherproblem bekommt und der server dann halt ein rst-signal sendet.

    nee, das regelt tcp schon. wenn einer wenig platz hat, dann sendet der andere weniger oder wird ganz gestoppt, bis wieder speicher da ist. da gibt's kein RST.

    ...aber wenn sich dein testserver auch so komisch verhält, dann sollteste vielleicht doch noch'n scharfen blick auf den client werfen...



  • Kann dir nur zustimmen

    aber was soll gross an den Befehl:
    send(mySock,msg,(my.laenge_nutz+21),0)

    falsch sein?
    mySock steht für den Socket
    msg ist das unsigned array was geschickt werden soll
    my.laenge_nutz+21 ist die komplette lanege von msg

    und wie schon mal erwähnt bis 132 laenge klappt es
    ab 133 Bytes geht gar nichts mehr

    und das schärfste ist wenn ich ein array von 133 laenge habe und nur versuche die ersten 132 stück zu übersenden kommt auch nix an (und an der verbindung liegt es nicht weil ich gleich als testversion ein kleinen datenstrom hinterherjage fürs überprüfen ob der Server funkst)



  • So nach vielen rum probieren am Server und am Client funkst es zumindestens das grosse Byte Ströme versendet werden. Woran es lag keine Ahnung

    ABER WENN ICH IMMER NOCH VIELE VIELE PAKETE HINTEREINANDER VERSCHICKE WERDERN IMMER NOCH TCP PAKETE VERSCHLUCKT



  • wertest du eigentlich den rückgabewert der 'send' funktion aus?
    der sagt dir nämlich, wieviele bytes der socket angenommen hat. sollte er kleiner sein als das, was du versenden wolltest, dann musste den rest auch noch hinterherschicken...



  • Natürlich werte ich die rückgabe aus die gesendet wurde, die stimmt auch immer überein

    Aber nach weiteren vielen rumprobieren funkst es jetzt:

    Ich versteh die Welt zwar nicht, aber es funkst

    Komischer weise muss ich ein byte mehr senden als wirklich notwendig ist, (also der Server bekommt ein byte mehr als er sollte) aber mit diesem zusätzlichem NULL Byte was der Server sogar nicht erhält funkst alles so wie ich es wollte. Es werden auch keine TCP Paket verschluckt.

    Wie schon gesagt ich verstehs nicht aber es funktioniert.

    Vielen Dank für deine aufgewendete Zeit und deine Denkanregungen
    und die tipss


Anmelden zum Antworten