WSARecv: Verstehe Konzept nicht
-
Hallo Leute,
ich arbeite gerade an einem kleinen Projekt und dafür muss ich mit WSARecv() umgehen können. Nur verstehe ich das Prinzip dahinter nicht, wie diese Funktion Daten empfängt und wie man sie erhält. Es gibt zwar ein kleines Beispiel im MSDN Eintrag von WSARecv() aber das erklärt nicht, wie man die empfangenen Daten, z.B. als char-Zeiger erhält, wie beim normalen recv(). Vllt. kennt der eine oder andere hier Tutorials, die erklären, wie man die Funktion verwendet oder vllt. hat jemand von euch auch Zeit und Lust mir das zu erklären.
Ich wäre euch echt dankbar.Mfg
-
Du erhälst beim recv auch nicht die Daten "als char Zeiger". Bei beiden Versionen gibt Du einen Buffer an, in den die Daten die empfangen werden geschrieben werden. Was Du mit dem Buffer machst oder wie Du diesen interpretierst ist alleine Deine Sache.
-
Ja, du hast recht, vllt. habe ich mich da ungenau ausgedrückt. Aber ist es bei WSARecv() nicht so, dass es sein kann, dass im angegebenen Buffer sich die empfangenen Bytes "vermischen". So habe ich das auf meiner bisherigen Google Suche jedenfalls besprochen vorgefunden und das verwirrt mich. Wie kann ich dann unterscheiden, welche Bytes im Buffer nach dem letzten Call von WSARecv() empfangen wurden und zu meinem Aufurf gehören? Und es stimmt doch auch, dass es sein kann, dass nach einen einmaligen Aufruf von WSARecv() nicht alle Bytes empfangen wurden? Woher weiß ich dann, wann alle Bytes empfangen wurden?
-
Das bleibt dir überlassen, wie du das handhabst. Wenn du in einen Puffer beim 1. WSARecv Aufruf 100 Bytes liest, und beim 2. Aufruf wieder 100 Bytes, dann überschreibt der 2. Aufruf die Daten des 1. Aufrufs.
Gibt zwei Lösungen:- Du kopierst die empfangenen Daten dahin, wo sie beim nächsten Aufruf nicht überschrieben werden
- Du liest in einen anderen Empfangspuffer
Edit:
Du kannst nicht wissen, wann alle Bytes empfangen worden sind, wenn du keine Informationen dazu in deinen Telegrammen bereitstellst. Bei ASCII Telegrammen könnte eine 0 ein Telegramm abschließen, oder du übermittelst die Telegrammlänge mit. Hängt halt vom Protokoll ab.
-
... und ist beim 'normalen' recv genauso!
-
Das Resultat ist aber nicht dasselbe, wie mit Recv... Im Buffer befinden sich Bytes, die eindeutig nicht zum letzten WSARecv() call gehören, aber laut dem lpNumberOfBytesRecvd gerade erst empfangen wurden.
Es geht mir primär um das overlapped Modell, das ich nicht verstehe.
-
Es macht erst Sinn in den Buffer hineinzusehen, wenn auch die overlapped Operation beendet ist.
