Problem mit winsock

TCP oder UDP?

Markus schrieb:
> Der Unterschied besteht
> ja soweit ich weiss nur in der Verwendung einer anderen Funktion, statt
> recv heißt es dann eben recvfrom.

Ui.
Diese Aussage hinkt gewaltig.
Das ist für mich ungefähr so, wie wenn einer sagt, der Unterschied 
zwischen Free-Climbing und 'Mit-der-Seilbahn-auf-den-Berg-fahren' 
besteht in einer anderen Rucksackform.

> mir ist der Unterschied zwischen TCP und UDP schon klar. Mein Problem
> ist aber die recvfrom Funktion, diese gibt mir zwar die Anzahl der Bytes
> zurück, z.B. 25 aber wenn ich die Daten dann ausgeben will ist der
> String seltsamer weise manchmal leer. Ich steuere ja ein Messgerät an,
> ich schicke ein Befehl hin (funktioniert) und warte auf die Bestätigung
> und danach auf die Daten. Manschmal geht es auch teilweise, dann kann
> ich z.B. die Befehlsbestätigung auslesen, nur eben nicht immer. Das will
> mir nicht in den Kopf.

Dein Fehler ist in der Anschauung, dass du mit einem recv die Daten 
genau so bekommst, wie der Sender sie weggeschickt hat. Dem ist nicht 
so.
Der ganze Netzwerkunterbau kann die Daten in mehrere Pakete aufteilen 
und getrennt auf den Weg schicken.
Es kann auch sein, dass der Netzwerkunterbau schon den Anfang der Daten 
in einem Paket weggeschickt hat, während der Datenerzeuger eine kleine 
Pause eingelegt hat um die nächsten Daten für das (seiner Meinung nach) 
immer noch gleiche Paket zusammenzustellen.

Du brauchst eine Minimalform eines Protokolls. Ohne geht es nicht.
Entweder der Sender schickt ganz am Anfang mit, wieviele Bytes er zu 
senden gedenkt oder in den Daten ist eine Markierung drinnen "Jetzt ist 
der Datensatz komplett".

Deine Leseroutine muss unter Umständen recv mehrmals aufrufen um den 
Datensatz wieder komplett zusammenzustellen. Und genau dafür benötigst 
du vom Sender noch zusätzliche Information, wann das der Fall ist. Eben 
dann, wenn die Anzahl der Bytes übertragen wurde bzw. wenn die Daten 
mittels einer Markierung als zu Ende markiert wurden.

UDP ist dann noch ein ganz anderes Thema. Da können deine Daten, so sie 
in mehreren Paketen aufgeteilt sind, in beliebiger Reihenfolge 
daherkommen; da kann dann auch schon mal ein Datenpaket fehlen etc. 
Sprich: Du kannst dich auf gar nichts mehr verlassen.

Markus schrieb:
> ja du hast recht, mein Messgerät schickt zuerst ein Byte, welches die
> Anzahl der nächsten dazugehörigen Bytes beschreibt. An Mehrfach-Aufruf
> hab ich schon gedacht, aber das ist ja erst der nächste Schritt.

Nein, das ist nicht der nächste Schritt.
Das ist der erste Schritt:
Aus den einlangenden Paketen wieder einen Datenstrom zu machen, aus dem 
die Datensätze herausgefischt werden.

> einen String so zu markieren das recv versteht, das es sich um
> hexadezimalzahlen handelt und nicht um den ASCII Zeichensatz.

Auf dieser Ebene gibt es keine Strings mehr.
Da gibt es nur noch Bytes. Was immer du an Bytewerten in dein Bytefeld 
hineinstopfst, bleibt auch so drinnen. Du Tatsache, dass du hier von 
Strings redest, lässt mich schon Schlimmes vermuten.

PS: Lass dich nicht davon verwirren, dass sendto auf deinem System ev. 
einen char* als Argument nimmt. char* war früher die übliche 
Schreibweise für 'Pointer auf alles'. Heutzutage würde man einen void* 
dafür benutzen, aber es ist nichts schwerer auszurotten als alte 
Gewohnheiten bzw. Kompatibilitäten.

1

  unsigned char SendBuffer[10];

2

3

  SendBuffer[0] = 0x12;

4

  SendBuffer[1] = 0x78;

5

  SendBuffer[2] = 'd';

6

  SendBuffer[3] = 'e';

7

8

  sendto( serverSocket, SendBuffer, 4, ...

9

10

  //

11

  // oder:

12

  // sendto( serverSocket, (char*)SendBuffer, 4, ...

gast schrieb:
> eine Frage muss ich doch noch stellen, von meinem Messgerät(laut manual)
> müsste ich eigentlich hexadezimale Zahlen empfangen, das Problem ist nur
> das diese Hexadezimalzahlen von recv wieder als ASCII-Zeichenfolge
> ausgegeben werden .z.B FO wird als ö ausgegeben, wie bekomme ich das nun
> hin, das als hexadezimal zeichen auszugeben. zu meiner Verdeidigung
> möchte ich noch sagen, das ich kein Informatiker der Programmierer bin.
> Ist alles Neuland für mich

Von deinem Messgerät kommen weder Texte noch hexadezimale Zahlen noch 
sonst irgend etwas. Von deinem Messgerät kommen Bytes, die einen Wert 
haben.
Wie du diese Bytes anzeigst ist dein Bier.
Ob F0 als ö ausgegeben wird oder als 0xF0 oder als 240 oder als 
Pixelmuster, hängt ausschliesslich davon ab, wie du ausgibst. Deswegen 
ändert sich aber der Bytewert nicht. Der Bytewert ist immer dergleiche: 
die oberen 4 Bit auf 1, die unteren 4 Bit auf 0

Im Rechner gibt es keine Texte, es gibt keine Hexwerte, es gibt keine 
Dezimalzahlen. Es gibt ausschliesslich Bitmuster! Was diese Bitmuster 
bedeuten, interessiert den Rechner nicht. Ein Bitmuster kann alles 
mögliche sein: Sie kann ein Opcode sein, der einen Befehl für die CPU 
kodiert. Es kann mithilfe des ASCII Codes als ein bestimmmter Buchstabe 
(bei der Ausgabe) interpretiert werden. Nimmt man anstelle des ASCII 
Codes den EBCDIC Code, so wird dasselbe Bitmuster als ein anderer 
Buchstabe angezeigt. Es kann bei der Ausgabe wahlweise als Hex-, 
Dezimal-, Binär-, Oktal- oder zu jeder anderen beliebigen Basis 
ausgegeben werden. Das Bitmuster kann als Codierung augefasst werden, 
welche Lämpchen aufleuchten sollen und welche nicht oder welche Relais 
ein bzw. aus sein sollen ....

Aber egal, wie dieses Bitmuster bei der Ausgabe interpretiert wird, im 
Rechner ist es immer nur dasselbe: eine Zahl gebildet aus dem 1-0 
Bitmuster von ein paar Bits (genaugenommen ist es im Rechner eigentlich 
nur ein Bitmuster. Selbst die Auffassung einer Zahl ist schon eine 
Interpretation dieses Bitmusters). Welche Bedeutung diese Bits haben, 
bestimmst du als Programmierer bzw. spätestens dann, wenn du das 
Bitmuster irgendwo zur Anzeige bringst.

> wie bekomme ich das nun
> hin, das als hexadezimal zeichen auszugeben

Wie wäre es erst einmal damit, ein C-Buch durchzuarbeiten?
Ungefähr in Kapitel 3 (von 60) werden dort die ersten Ausgabevarianten 
durchgesprochen, was man so alles mit dem Formatstring von printf 
anstellen kann und welches % Kürzel wofür steht.
Wenn du dich an Netzwerke heranwagst, solltest du diese Dinge eigentlich 
aus dem FF beherrschen.

1

malloc buf + 1

wird dir niemand kompilieren, also zurück zum Start!
Ich verstehe deine letzte Frage auch nach dreimaligem Lesen nicht
so recht. Kann an mir liegen, erfahrungsgemäß ist sie aber wohl
einfach zu unklar formuliert.

Wo bekommst du nur ein Zeichen?

Kann es sein, daß du irgendwo die Daten verwendest, ohne eine
abschließende 0 anzuhängen, aber dich auf die 0 verlässt?
Z.B. zur Ausgabe eines Strings, den du mit recv() oder
so etwas bekommen hast, wirst du in der Regel selbst die
terminierende 0 anhängen müssen, bevor du den String mit
puts(), printf() o.s.ä. verwenden kannst.
Dazu muss der Puffer natürlich auch groß genug sein, also
Länge der Nutzdaten + 1.

Wenn der Quelltext vernünftig formatiert wäre, könnte man ihn auch 
lesen...

Wer gibt eigentlich den Speicher im Fehlerfall frei?

Wenn du maximal buf Zeichen liest, musst du buf+1 Zeichen allokieren, um 
Platz für die abschließende 0 zu haben.

data[1] ist kein String, sondern ein Zeichen.

kleiner Tip:
Bevor ich mich mit Netzwerk herum ärgere, würde ich vielleicht erstmal
die Grundlagen von C lernen.

Und bei vernünftigen Fragen (ordentlich beschrieben, lesbarer Quelltext)
bekommt man auch leichter vernünftige Fragen. So macht es wenig Spaß.

Markus schrieb:
>     else
>
>        {
>
>    // data[byt]='\0';
>     //int len=strlen(data);
>     //char *xa=malloc(byt+1);
>
>     //strcpy(xa,data);
>     data[byt]='\0';
>     return data;//&data;
> }
>     }
>
> }

Du hast es immer noch nicht.
Lies es von meinen Lippen ab:
Auf dieser Ebene hast du keine Strings mehr! Hier gibt es nur noch 
Bytes, keine Strings. Damit aus einer Abfolge von Bytes in C ein String 
wird, müssen ein paar wichtige Regeln eingehalten werden! Eine davon 
ist: Sobald ein 0-Byte auftaucht, ist der String zu Ende!

Daher ist die Verwendung von Stringfunktionen auf dieser Ebene absolut 
kontraproduktiv. Vor allem dann, wenn dir dein Messgerät keine Texte 
sondern einfach nur eine Bytefolge schickt. Niemand garantiert dir, dass 
in so einer Bytefolge nicht ein 0-Byte enthalten ist. Es ist sogar sehr 
wahrscheinlich, dass dem so ist.

Um mit Bytes zu arbeiten gibt es die Familie der mem... Funktionen. 
Vergiss str... an dieser Stelle. Das führt dich immer wieder in eine 
Sackgasse.

Und nochwas: Wenn du mit Bytes arbeitest, dann ist der Datentyp der Wahl 
'unsigned char' und keinesfalls 'char'. Das öffnet nämlich den nächsten 
Sack an Problemen.

> Ich verwende auch
> ein C-Buch, hab nur eben aufgrund des Zeitdrucks ein paar Kapitel
> übersprungen.

Das ist keine gute Ausrede. Du hast ja auch noch die Nachtstunden

> ja du hast recht, mein Messgerät schickt zuerst ein Byte, welches die
> Anzahl der nächsten dazugehörigen Bytes beschreibt.

Schickt das Messgerät auch noch ein eindeutiges Byte, wenn ein Datensatz 
zu Ende ist?
Das wäre wichtig, damit man die Kommunikation wieder synchronisieren 
kann, falls aus irgendeinem Grund Sender und Empfänger asynchron werden.

Deine Empfangsfunktion müsste in etwa so aussehen

1

unsigned char * readData()

2

{

3

  SOCKADDR_IN remoteAddr;

4

  int remoteAddrLen = sizeof( remoteAddr );

5

  int bytesReceived = 0;

6

  int totalBytesReceived = 0;

7

  int expectedBytes = 0;

8

  unsigned char data[256];  // kann nicht größer sein, da die

9

                              //  gesendete Längenangabe 1 Byte ist.

10

  unsigned char * returnData;

11

12

  bytesReceived = recvfrom( s, data, sizeof(data), 0,

13

                           (SOCKADDR*)&remoteAddr, &remoteAddrLen );

14

15

  // das erste empfangene Byte gibt die Länge des Datensatzes an

16

  expectedBytes = data[0];

17

  bytesReceived--;

18

19

  returnData = malloc( expectedBytes + 1 );  // nur um sicher zu gehen

20

                                             // 1 mehr und dann zum

21

                                             // Schluss noch ein \0 rein

22

23

  //

24

  // aus dem empfangenen ersten Paket erst mal alles

25

  // auf die Seite bringen was da ist

26

  //

27

  memcpy( returnData, &data[1], bytesReceived );

28

  totalBytesReceived = bytesReceived;

29

30

  //

31

  // warte jetzt auf den Rest der noch fehlt

32

  //

33

  while( totalBytesReceived < expectedBytes ) {

34

    bytesReceived = recvfrom( s, data, sizeof(data), 0,

35

                              (SOCKADDR*)&remoteAddr, &remoteAddrLen );

36

37

    // Noch Daten eingetrudelt?

38

    if( bytesReceived > 0 ) {

39

      // die neuen Daten an das bisher Empfangene anhängen

40

      memcpy( &returnData[ totalBytesReceived ],

41

              data,

42

              bytesReceived );

43

      // und damit sind wir dem Endziel, nämlich expectedBytes Bytes

44

      // zu empfangen, wieder ein Stückchen näher

45

      totalBytesReceived += bytesReceived;

46

    }

47

    else if( bytesReceived == SOCKET_ERROR ) {

48

      free( returnData );

49

      return NULL;

50

    }

51

  }

52

53

  // Das wars. Die Anzahl der erwarteten Bytes ist da

54

  // Zur Sicherheit, wenn es ein String ist, noch hinten

55

  // eine 0 anhängen.

56

  // Wenn die Daten Binärdaten sind, darf das nicht passieren!

57

  returnData[ expectedBytes ] = '\0';

58

  return returnData;

59

}

Achtung: Ich habe den Code nicht getestet sondern blind geschrieben. Er 
sollte zumindest dicht drann sein. Am besten im Debugger durchsteppen 
und sich alle Variablen ansehen und was da so alles passiert.

Um Fehlerbehandlung musst du dich auch noch kümmern.
Was aber auf keinen Fall sein kann: Dass mir eine readData Funktion den 
socket schliesst. Das ist nicht ihre Aufgabe! Die Funktion soll Daten 
empfangen. Wenn es dabei ein Problem gibt, soll sie das melden. Aber 
ansonsten soll sie die Finger vom Socket lassen.

Mit dem malloc da drinnen bin ich absolut unglücklich. Ist nur wieder 
ein Stolperstein, dass der Aufrufer den free vergisst.
Besser wäre es, wenn deine Funktion so aussehen würde

1

int readData( unsigned char * recBuffer, size_t bufferLen )

2

{

3

   ...

4

}

Die Funktion readData kriegt einen Buffer (der gross genug sein muss, 
Längenangabe in bufferLen) in dem sie die Daten abzuliefern hat. Als 
Returnwert liefert sie die Anzahl der Bytes, welche sie in den Buffer 
gestellt hat.

Markus schrieb:
> ja danke, das ist ein sehr guter Anhaltspunkt.

Diese Funktion ist noch nicht einmal ansatzweise dort, wo sie eigentlich 
sein müsste.

Wenn dein Messgerät mehrere Antworten in kurzer Folge hintereinander 
schickt, dann wird das Probleme geben. Da müsste man noch eine FIFO 
dazwischen schalten, die den überschüssigen Anteil nach den jeweiligen 
recvfrom aufnimmt. Und die readData müsste als allererstes in diese FIFO 
schauen um zu sehen, ob da noch nicht verarbeitete Bytes rumlungern und 
sich zuerst von diesen bedienen, ehe sie mittels recvfrom die FIFO 
wieder füllt.
Und aus genau dem gleichen Grund können die memcpy kräftig in die Hose 
gehen.

Stell dir einfach vor, aus dem ersten recvfrom kommt diese Bytefolge 
raus

  0x05 0x10 0x20 0x30 0x40 0x50 0x08 0x10 0x20

und dann gehst du am Papier die Funktion durch.
Hinweis: In dieser Bytefolge sind 2 Antworten vom Messgerät enthalten! 
Die erste (mit einer Länge von 5) ist komplett, die zweite (mit einer 
Länge von 8) ist noch nicht komplett.

Trotzdem müssen beide Antworten bei 2 Aufrufen von readData korrekt 
entschlüsselt und richtig aufgeteilt werden.

Bei solchen Sachen ist überhaupt Papierarbeit sehr wichtig! Vor allem 
wenn man das noch nie gemacht hat! Es bringt nichts, da auf gut Glück 
den Code zu verändern. Du brauchst reproduzierbare Verhältnisse und du 
musst dir über jede einzelne Anweisung im klaren sein was sie macht, 
warum sie da ist und was ihre Aufgabe ist.