TCP/IP Socket Prgrammierung-Probleme beim Senden/empfangen

Gehts auch genauer?
Welches Betriebssystem?
Was schickst du, und was empfängst du?
Hast du an Netzwerk-Byteorder gedacht?

Sorry, aber bei meiner Glaskugel ist der Akku grad alle.
Ansonsten ist dein Fehler in Zeile 42 zu finden...

Ein gerne gemachter Fehler bei recv() ist anzunehmen das in einem Aufruf 
alle Bytes ankommen. Man muss aber in einer Schleife solange Bytes 
sammeln bis ist=sollanzhl ist oder recv() einen Fehler oder anz=0 => 
Verbindungsabbruch meldet.

Ich benutze ein Beaglebone black, mit Neutrino RTOS Betriebssytem.

Mein Sendeteil sieht so aus:

1

if(send(IDclient,&ADCbuffer[n],1,0)!=-1)

2

printf("Sende Signal:%d\n",ADCbuffer[n]);

ADCbuffer ist ein uint32_t Array. In dem Fall schicke ich eine "1".
Erhalte eine "134529632".

Aber für was steht dann das size an der 3.Stelle in der recv-Fkt. ?

QX schrieb:
> In dem Fall schicke ich eine "1".
Schickst du eine "1", oder eine '1' oder eine 1?

QX schrieb:
> Aber für was steht dann das size an der 3.Stelle in der recv-Fkt. ?
Aus Linux, man recv

Das Size steht schon für die Sollanzahl, aber es ist nicht garantiert 
das die Daten tatsächlich in einem Rutsch kommen. Gilt hauptsächlich für 
non-blocking sockets, aber auch bei blocking muss man mit Fehlern oder 
Verbindungsabbruch rechnen. Und TCP vorausgesetzt.

Jojo S. schrieb:
> Das Size steht schon für die Sollanzahl

Nicht wirklich. Das steht eigentlich für die Buffergröße, also die 
Maximalanzahl von Bytes, die recv da reinschreiben darf.
Steht ja auch explizit so in dem von Kaj geposteten Screenshot

Jojo S. schrieb:
> Das Size steht schon für die Sollanzahl

Glaub ich eher weniger...
http://www.qnx.com/developers/docs/6.4.1/neutrino/lib_ref/r/recv.html

1

len

2

The size of the buffer.

Nix mit Sollanzahl, sondern länge des Puffers in den geschrieben wird.

Martin K. schrieb:
> d) Lese auch genügend Bytes mit recv(IDMySocket, ctr,
> 1*sizeof(uint32_t),0)

Und überprüfe ob auch tatsächlich 1*sizeof(uint32_t) Bytes gelesen 
wurden!

Jojo S. schrieb:
> Das Size steht schon für die Sollanzahl, aber es ist nicht garantiert
> das die Daten tatsächlich in einem Rutsch kommen. Gilt hauptsächlich für
> non-blocking sockets, aber auch bei blocking muss man mit Fehlern oder
> Verbindungsabbruch rechnen. Und TCP vorausgesetzt.

Das hat nichts mit Fehlern oder Verbindungsabbrüchen zu tun. Es wird das 
zurückgeliefert, was verfügbar ist. Das muß auch bei normaler Verbindung 
nicht unbedingt soviel sein, wie man als Size angegeben hat. Es muß auch 
nicht soviel sein, wie der Sender am Stück an seine send-Funktion 
übergeben hat.
Deshalb muß man bei solchen Syscalls wie recv oder read eigentlich in 
einer Schleife so lange lesen, bis man die gewünschte Datenmenge 
erhalten hat. Und man muss auf Fehler prüfen, denn nicht jede Fehler 
bedeutet kompletten Abbruch, sondern manch einer erfordert einfach einen 
erneuten Leseversuch.

QX schrieb:
> ctr=malloc(sizeof(int));

Warum allokierst du den int denn dynamisch?

Martin K. schrieb:
> Es ist richtig das die Datenpakete von den TCP/IP Stacks nicht unbedingt
> am Stück gesendet oder empfangen werden müssen. Aber wenn die Pakete
> klein genug sind, nicht irgendwo fragmentiert werden und NAGLE nicht
> abgeschaltet wurde, dann ist es doch sehr wahrscheinlich, dass das an
> Bytes ankommt, was auch gesendet wurde.

Ja, wenn x und wenn y und wenn z, dann geht's wahrscheinlich...
Und nächste Woche kommt die nächste Frage, warum's nicht mehr klappt, 
wenn er größere Pakete sendet.

Martin K. schrieb:
> Es ist richtig das die Datenpakete von den TCP/IP Stacks nicht unbedingt
> am Stück gesendet oder empfangen werden müssen. Aber wenn die Pakete
> klein genug sind, nicht irgendwo fragmentiert werden und NAGLE nicht
> abgeschaltet wurde, dann ist es doch sehr wahrscheinlich, dass das an
> Bytes ankommt, was auch gesendet wurde.

Ja super Aussage, leider unbrauchbar!

Wir haben mal Wochen einen selten auftauchenden Fehler in einer 
selbstgeschriebenen recht umfangreichen Mittelware gesucht, bis wir 
durch Codeanalyse das tatsächliche Problem gefunden hatten. Ursache war, 
dass in der untersten Ebene erst ein 2 Byte Wert für die Größe des 
nachfolgenden Datenblocks und dann die Daten selbst gesendet und 
empfangen wurden.
Der Empfänger hat zwar schön in einer Schleife die Daten 
zusammengesammelt, aber bei der 2Byte Länge ist er davon ausgegangen, 
dass die ja in einem Rutsch kommt. Klar aber nur bei 99,995% aller 
Fälle.

Merke: Man kann sich NIE NIE NIE sicher sein, dass man alle Bytes auf 
einmal empfängt!

Karl H. schrieb:
> Jede windige Annahme, die man erst mal akzeptiert, gerät im laufe der
> Zeit in Vergessenheit und wartet nur darauf zuzuschlagen. Natürlich
> dann, wenn sie maximalen Schaden anrichten kann.

Jepp, ich habe schon einige Arbeitszeit damit verbraten solche 
Zeitbomben zu finden. Eigene und noch öfter die von anderen.