Suchergebnisse

Zitat von EaranMaleasi: „Muss ich eventuell diese Pakete splitten?“ Das macht Tcp schon von selber und genau das ist wahrscheinlich auch dein Problem. Bei Tcp empfängst du nicht garantiert genau die Daten länge die du gesendet hast, sondern kannst evtl. deine Daten in mehreren kleinen Teilen empfangen. Entweder arbeitest du mit einem NetworkStream oder packst eine Size Angabe mit in dein Array und beachtest diese Size Angabe beim Empfangen.

Vllt. entschlüsselst du falsch oder machst irgendwo anders was falsch? Tcp ändert nicht einfach mal so die Daten.

Poste doch einfach mal paar Code Auszüge wie du deine Pakete ausliest/schreibst und wie du sie verschlüsselst/entschlüsselst.

Erstmal: Du verwendest SocketAsyncEventArgs falsch. SocketAsyncEventArgs nutzt man um die Resourcen die dafür erstellt werden neu zu verwenden statt sie bei jeder Operation neu zu erstellen. z.B. erstellt man einen Pool mit x SocketAsyncEventArgs Objekten und die Read/Write Operationen holen sich dann ein Objekt aus dem Pool, sobald es nicht mehr gebraucht wird wirft man das wieder in den Pool. Wenn man hin geht und jedes mal das SocketAsyncEventArgs Objekt neu erstellt kann man auch gleich die …

Ja. Du schaust ob die Anzahl der empfangenen Daten deiner Size Angabe übereinstimmt, falls nicht speicherst du die Daten irgendwo und rufst noch mal receive auf. Das machst du solange bis dein Paket komplett ist. So mach ich das in meiner Library: (Versteckter Text)

Keine Ahnung ob es auch nur 1 byte lang sein kann, sollte man aber trotzdem bedenken. Tcp splittet deine Daten in mehrere Pakete, falls nötig, und da kann es halt vor kommen, dass du die bereits empfangenen Daten abrufst bevor alles da ist. Was genau da passiert weiß ich selber nicht, so sehr hab ich mich nun auch wieder nicht mit dem Thema beschäftigt :>.

Zitat von ThuCommix: „Das Problem hatte ich noch nie“ Wenn man nur wenig Daten sendet kommt das auch nur selten vor(Auch Lokal und im LAN wird man eher selten drauf stoßen). Wenn man größere Daten sendet und das über das Internet wird man auf jeden Fall auf das Problem stoßen. Die Verhaltensweiße ist überall so, egal ob Begin/End, SocketAsyncEventArgs, synchronen Funktionen oder NetworkStream.

Tcp ist ein Stream von Daten. Das was du sendest wird nicht, wie bei Udp, als komplettes Paket angesehen sondern als Daten die auf einen Stream geschrieben wurden. Es wird ein Teil vom Stream genommen und übers Netzwerk gesendet, Tcp weiß nicht was davon jetzt dein ganzes Paket ist. Tcp sorgt nur dafür, dass deine Daten sicher und fehlerfrei ankommen.

Mit dem NetworkStream hat man genau das selbe Problem. Die Read Funktion funktioniert genauso wie die Receive Funktionen vom Socket. Da müsste man dann den BinaryReader verwenden, welcher dann aber nur synchrone Funktionen anbietet ;).

Hier mal 3 gute Open Source Projekte: codeproject.com/Articles/15528…munication-Implementation github.com/kerryjiang/SuperSocket codeproject.com/Articles/56362…cket-Client-Server-system Schauts euch an und macht euch selbst ein Bild wie ihr es für eure Zwecke am besten umsetzen könnt.