rausfinden wieviel Bytes beim revc() angekommen sind?



  • Hallöchen,

    also habe eine Frage zu diesem Thema schon gefunden, leider wurde diese nicht voll beantwortet.
    Also ich sende ein recv auf einen IMAPServer, nun bekomme ich entsprechende Antworten vom Server, die aber leider manchmal größer als 1024 byte (oder werden einfach auch so in mehere Pakete gepackt)sind. So müsste ich ggf noch einmal die Funktion recv aufrufen. Woher weiß ich denn nun definitiv, ob ich dieses muss, also Daten noch zur Abholung bereit stehen, oder nicht??
    Es muss doch nen flag geben oder ne Funktion mit der ich das kann. Habe google auch schon vergewaltigt.....

    Hier der Beitrag von jemand anderen, wo keine richtige
    Antwort zurück kam: http:
    //www.c-plusplus.net/forum/viewtopic.php?t=17231&highlight=recv+anzahl

    Alos vielen Dank für eure konstruktiven Beiträge Gruß Christopher



  • krille schrieb:

    Also ich sende ein recv

    So so.

    die aber leider manchmal größer als 1024 byte (oder werden einfach auch so in mehere Pakete gepackt)sind. So müsste ich ggf noch einmal die Funktion recv aufrufen. Woher weiß ich denn nun definitiv, ob ich dieses muss, also Daten noch zur Abholung bereit stehen, oder nicht??

    IMAP sollte eigentlich u.a. den syntaktischen Aufbau einer Serverantwort definieren. Beispielsweise (ich kenn IMAP konkret nicht) könnte sie durch ein Newline abgeschlossen sein. Jetzt recv'st du solange, bis das newline da ist.

    Das ist die einfachste und IMHO auch korrekte Lösung. Mit dem Vorschlaghammer (select) gehts auch. BTW gibt es in TCP keine Pakete.

    Auch hat das alles im ANSI-C-Forum nichts verloren. Unix oder Windows?



  • Hallo,

    ich finde es ja super , dass ich hier gleich eine Antwort bekomme.
    Ich programmiere unter C und verwende dementsprechend auch die funktion recv aus der socket.h. Also hinzu kommt, dass ich dass Programm unter Unix und Windows implementieren muss.
    Also bin ich hier doch richtig!!Oder nicht??
    Soll ich jetzt nen neuen Thread in Unix eröffen??

    Zurück zum Problem.. Vom Server kommt natürlich ein \r\n zurück(Was du auch meinst)
    dieses kommt aber auch nach jeder Zeile. Da ich hier möglicherweise mehrere Zeilen habe kann man nicht so einfach suchen nach \r\n und schluss machen, also muss es nen anderen Weg geben. Habe auch schon das RFC von Imap, aber nicht so wat gefunden .
    Vielleicht noch jemand eine andere Idee??
    Gruß Krille
    Und warum gibt es in TCP keine Pakete??



  • krille schrieb:

    Also bin ich hier doch richtig!!

    Nein, hier geht es um die Sprache C, nicht um betriebssystemspezifische Erweiterungen (Sockets z.B.). Am besten warten, bis ein Moderator das Posting verschiebt.

    Zum Problem: Hmm hässlich. Ist die Serverantwort völlig unstrukturiert? Man muss doch irgendwie die Grenze zwischen zwei Nachrichten herausbekommen können.
    Eine Brute-Force-Variante wär natürlich man: select(2).

    Und warum gibt es in TCP keine Pakete??

    TCP ist ein Byte-Strom ohne weitere Unterteilungen. Der wird natürlich intern in Segmente aufgeteilt, die dann in Form von IP-Paketen über den Äther gehen, aber aus Benutzersicht existieren diese Pakete nicht.



  • Moin,

    also ich habe wieder mal ins rfc geguckt. Habe aber leider nichts gefunden.
    Habe mal versucht recv auf nonblocking zu setzen, so wartet meine funktion auf keine Antwort mehr bzw. es dauert ja kurze Zeit bis vom ImapServer eine Antwort kommt, auf die er eben nicht wartet und so auch nicht verarbeitet. Also das Nonblocking funktioniert nur , wenn ich wirklich weiß, dass ab einem Punkt keine Daten mehr kommen, wo ich wieder bei meinem Problem wäre.
    Ich weiß nicht weiter und das Projekt muss bis Anfang Januar stehen...
    HIIIILLLFFFEEEEEE
    Gruß Krille

    An Admin: bitte in nach Unix verschieben ... Danke



  • Kannst du das Empfangen der Daten nicht in einen Thread auslagern??



  • Hallo,

    nein Threads wären nicht die Lösung, denn das Programm soll sequentiell ablaufen.Bei einem Thread läuft doch eine Endloschleife ab, solange du nicht abbrichst, das ist nicht , was ich brauche. Bei mir ist es so, dass ich ein send() schicke, dann rufe ich ein recv() auf und will die Daten(pakete) verarbeiten.Wenn ich nun explizit ca. 5 sek. warte entspricht das nicht wirklich einer guten Programmeffiziens. Ich muss einfach wissen, ob noch Pakete kommen. Vielleicht anhand es IP- Headers??, aber es muss doch einfacher gehen!!. Ich werd verrückt :-), aber danke für deinen Beitrag
    Gruß Krille



  • Ok, Threads willst du also nicht machen. Gut...

    Normalerweise geht man ja davon aus, dass das Ende der "Pakete" irgendwie angezeigt wird. Wird möglicherweise am Anfang übermittelt, um wieviele Pakete es sich handelt? Ist das letzte Paket leer? Gibt es spezielles Zeichen am Schluss?



  • Ja das denke ich mir ja auch, dass es irgendwie angezeigt werden muss. Aber wo und wie. Alles, was ich besher ausprobiert habe, war nicht so erfogreich. Habe mein recv() auch schon auf NONBLOCKING gesetzt. Tja dann kommt eben nichts mehr an. So das letzte Paket is irgendwann leer. Kannst aber auch nicht fragen , ob die zurückgelieferten bytes 0 sind , denn vorher wenn man das recv aufruft, wartet er bis wat kommt und es kommt ja nichts mehr also wartet und wartet und wartet er. Tja die Anzahl der Pakete würde ich gerne wissen, ober wo im IP-Header ja , aber wo??
    OK gruß Krille



  • Was wird denn genau übermittelt? Also was bekommst du von recv() zurück?



  • krille schrieb:

    Tja die Anzahl der Pakete würde ich gerne wissen, ober wo im IP-Header ja , aber wo??

    Bashar schrieb:

    TCP ist ein Byte-Strom ohne weitere Unterteilungen. Der wird natürlich intern in Segmente aufgeteilt, die dann in Form von IP-Paketen über den Äther gehen, aber aus Benutzersicht existieren diese Pakete nicht.

    Hör auf nach den nicht vorhandenen Paketen zu fragen.

    Wie Bashar schon gesagt hat, das IMAP-Protokoll muss doch irgendeine Struktur der Antworten definieren. Vielleicht steht am Anfang der Antwort ja "Content-Length:10144" o.ä., damit du weißt wie viel Bytes dich erwarten.


Anmelden zum Antworten