[SOCKETS] einzelnes Paket erzwingen



  • wenn du die nullen mitschickst, dann liesst du solange die bytes ein, bis eine null kommt. dann ist der string fertig und du kannst den nächsten einlesen. bei tcp/ip geht nichts verloren. wenn aus irgendeinem grund die verbindung abbricht wird der string, der gerade in bearbeitung ist verworfen.

    ...aber da gibt es viele andere möglichkeiten. man könnte z.b. vor jedem string die länge schicken (als 2 bytes etwa) und dann die null weglassen. ist auch nicht schlecht



  • net schrieb:

    wenn du die nullen mitschickst, dann liesst du solange die bytes ein, bis eine null kommt. dann ist der string fertig und du kannst den nächsten einlesen. bei tcp/ip geht nichts verloren. wenn aus irgendeinem grund die verbindung abbricht wird der string, der gerade in bearbeitung ist verworfen.

    ...aber da gibt es viele andere möglichkeiten. man könnte z.b. vor jedem string die länge schicken (als 2 bytes etwa) und dann die null weglassen. ist auch nicht schlecht

    die Lösung mit dem \0 am Ende gefällt mir am Besten, nur weiß ich jezt eben nicht genau wie ich das code-mäßig realisieren könnte....



  • nimm dir doch ein beispiel an HTTP



  • oder?? schrieb:

    nimm dir doch ein beispiel an HTTP

    mhh jetzt das komplette HTTP-Protokoll reinziehen... naja 🙄 😡



  • ich kenn das auch nicht so gut.

    ich glaube:

    im header werden die einzelnen zeilen mit \r\n getrennt. und dann kommt zum schluß des header \r\n\r\n und dann die daten



  • oder?? schrieb:

    ich kenn das auch nicht so gut.

    ich glaube:

    im header werden die einzelnen zeilen mit \r\n getrennt. und dann kommt zum schluß des header \r\n\r\n und dann die daten

    ok, aber bringt mich das jetzt irgendwie weiter^^ 🙄

    Ich wollte eigentlich ja nur noch wissen wie ich
    #nUsername#dUsername

    schön sauber zersplitten kann...



  • daten = webseite



  • mit c++ strings geht das nur sauber



  • oder?? schrieb:

    mit c++ strings geht das nur sauber

    hat denn jemand nen beispiel wie man das damit macht?



  • Rodney schrieb:

    die Lösung mit dem \0 am Ende gefällt mir am Besten, nur weiß ich jezt eben nicht genau wie ich das code-mäßig realisieren könnte....

    also empfangsseitig hab mal was hingehackt:

    int recvstring (SOCKET sock, char *s, int maxlen)
    {
    	int i = 0;
    	while (i < maxlen)
    	{
    		int res = recv (sock, &s[i], 1, 0);
    		if (res == 0)
    			return 0;
    		if (res == SOCKET_ERROR)
    			break;
    		if (s[i] == '\0')
    			return 1;
    		i++;
    	}
    	s[0] = '\0';
    	return 0;
    }
    

    aus'm kopf, wahrscheinlich fehlerhaft, aber so könnts gehen.
    (aber keine 2 nullen nacheinander senden)
    rückgabe: 1: es sind noch mehr strings da
    0: keine strings mehr da, verbindung normal beendet.
    0 und s[0] == 0: fehler, entweder string zu lang oder SOCKET_ERROR

    aufruf um einen string zu lesen:

    char s[256];
    recvstring (socket, s, sizeof(s));
    

    dann steht der string in 's'.
    musst halt noch 'ne schleife drumbasteln und immer neuen
    speicher übergeben (malloc oder statisches array oder wie auch immer)

    edit: senden ist ja trivial

    send (socket, string, strlen(string)+1, 0);
    


  • net schrieb:

    Rodney schrieb:

    die Lösung mit dem \0 am Ende gefällt mir am Besten, nur weiß ich jezt eben nicht genau wie ich das code-mäßig realisieren könnte....

    edit: senden ist ja trivial

    send (socket, string, strlen(string)+1, 0);
    

    Muss beim Senden nicht auch eine Schleife machen?

    If no error occurs, send returns the total number of bytes sent, which can be less than the number indicated by len.



  • Socket-Neuling schrieb:

    net schrieb:

    edit: senden ist ja trivial

    Muss beim Senden nicht auch eine Schleife machen?

    ja, ich meinte nur für einen string + der null.



  • Ja aber selbst für einen nullterminierten String ist doch nicht garantiert das er mit einem send-Aufruf geschickt ist. Oder?

    Das steht eben so in der Doku.



  • Socket-Neuling schrieb:

    Ja aber selbst für einen nullterminierten String ist doch nicht garantiert das er mit einem send-Aufruf geschickt ist. Oder?

    vielleicht bei nicht-blockierenden sockets oder wenn die verbindung abgebrochen ist. eigentlich sollte 'send' blocken, wenn kein platz mehr im sendepuffer ist.



  • ok danke, das ganze werde ich morgen mal testen.



  • die Funktion funktioniert leider nicht, er bleibt dort immer hängen (Endlosschleife)



  • Rodney schrieb:

    die Funktion funktioniert leider nicht, er bleibt dort immer hängen (Endlosschleife)

    ja, es ist ja auch nur ein beispiel dass ungefähr das prinzip zeigen soll. sollte aber funktionieren, wenn der sender strings sendet und wenn er fertig ist, die verbindung beendet.
    also 'recv' blockiert, wenn nichts im empfangspuffer ist. das ist normal. du könntest es in einen zweiten thread auslagern oder non-blocking sockets nehmen (dafür ist die funktion aber nicht ausgelegt).



  • net schrieb:

    Rodney schrieb:

    die Funktion funktioniert leider nicht, er bleibt dort immer hängen (Endlosschleife)

    ja, es ist ja auch nur ein beispiel dass ungefähr das prinzip zeigen soll. sollte aber funktionieren, wenn der sender strings sendet und wenn er fertig ist, die verbindung beendet.
    also 'recv' blockiert, wenn nichts im empfangspuffer ist. das ist normal. du könntest es in einen zweiten thread auslagern oder non-blocking sockets nehmen (dafür ist die funktion aber nicht ausgelegt).

    ich hab die Funktion bei mir aus der WM_SOCKET ausgerufen...

    Ich bekomme aber nur WM_SOCKET NAchrichten wenn etwas im Buffer vorhanden ist (FD_READ)



  • Rodney schrieb:

    ich hab die Funktion bei mir aus der WM_SOCKET ausgerufen...
    Ich bekomme aber nur WM_SOCKET NAchrichten wenn etwas im Buffer vorhanden ist

    ok, aber wenn das letzte byte keine 0 ist dann landet er wieder im 'recv'-aufruf und wartet bis wieder was gesendet wurde.
    wie gesacht, der code ist nur anschauungsobjekt. für deinen konkreten fall musst du schon was anpassen.


Anmelden zum Antworten