Ich schicke vom C# 30 Strings auf einaml!Die werden auch richtig abgeschickt jedoch werden sie in der ListView nicht angezeigt!Sprich es kommt die Hälfte der Strings(manchmal) auch weniger an!Mache ich jeden String einzeln kommen sie richtig an!
Jetzt meine Frage:
Kann es sein das die Sockets oder die ListView der C Programmes zu langsam sind?Wäre sehr nett wenn mir jemand rasch antworten könnte!

MFG

THX

man: recv

Was ist dann das Problem?

Sorry txp verbindung!
Wie meinst du "richtig interpretierst"!

naja, der rückgabewert sagt dir z.b., wie viele zeichen angekommen sind, ob die verbindung noch steht, abgebrochen oder regulär beendet wurde.
gleiches gilt übrigens auch für 'send'. wenn du 1000 bytes verschicken willst und der rückgabewert ist 476, dann hast du nur 476 bytes verschickt. den rest musst du hinterher senden.

JustMe01 schrieb:

Würde ich es ja nciht richtig interpretiern würden ja garkeine ankommen odeR...

...oder das passieren, was du beobachtest.

gleiches gilt übrigens auch für 'send'. wenn du 1000 bytes verschicken willst und der rückgabewert ist 476, dann hast du nur 476 bytes verschickt. den rest musst du hinterher senden.
[

qft. lesen/schreiben von/auf sockets immer in einer schleife und dabei rückgabewert entsprechend überprüfen. wenn der netzwerkstack voll ist, ist er voll. das betriebssystem akzeptiert erst dann wieder daten wenn sie tatsächlich versendet wurden. gerade bei tcp, wo die konsistenz sichergestellt wird, ist es nicht unüblich das nach einigen hundert bytes nach dem ersten sendeversuch schon schluss ist

Ich habe jedoch die Vermutung, dass nicht alle Daten richtig empfangen werden!

sorry, aber mit "ich vermute" und "mein programm funktioniert nicht" wird dir hier keiner weiterhelfen können.

Ich habe jedoch die Vermutung, dass nicht alle Daten richtig empfangen werden!

überprüf's doch damit: http://www.simplecomtools.com/tcptesttool.html

haterskater ist zwar ein kleines Kind welches gerne nervt und spottet, hat in diesem Fall aber wohl Recht.

Lies die Doku nochmal. Und halte dich von fragwürdigen Tutorials fern, sowie von Ratschlägen von Leuten die nicht selbst schon grössere, funktionierende Projekte mit Sockets programmiert haben.

@sothis_: Beim Senden hab' ich real noch nie einen Fall beobachtet wo weniger als "n" zurückgegeben wurde, zumindest nicht bei blocking Sockets. Was natürlich nicht bedeutet dass man Code schreiben sollte der davon ausgeht dass das immer so sein wird.

@sothis_: Beim Senden hab' ich real noch nie einen Fall beobachtet wo weniger als "n" zurückgegeben wurde, zumindest nicht bei blocking Sockets. Was natürlich nicht bedeutet dass man Code schreiben sollte der davon ausgeht dass das immer so sein wird.

oh wirklich? ich bin gerade auch am frickeln. mein sehr generisches protokoll on top of tcp sendet nachrichten der größe von bis zu 2mb. läuft der server auf dem selben rechner ist ein read in einem cycle durch. läuft er auf meinem dedizierten rechner und der client unter windows benötigt read im schnitt 50 aufrufe um die 2mb nachricht komplett zu empfangen, beim client auf linux benötigt read ungefähr 80 cycles.

edit: miscomprehension ftl. beim write tritt der fall natürlich nur selten auf, es sei den man spielt mit signalen herum, dann wiederum ist es essentiell write in eine schleife aufzurufen.

Beim Senden hab' ich real noch nie einen Fall beobachtet wo weniger als "n" zurückgegeben wurde, zumindest nicht bei blocking Sockets.

stimmt auch wieder. ein blocking socket sollte eigentlich blocken, wenn der sendebuffer voll ist.

Was natürlich nicht bedeutet dass man Code schreiben sollte der davon ausgeht dass das immer so sein wird.

doch sollte man, weil das garantiertes verhalten ist. man kann natürlich auch ne umständliche while schleife benutzen oder seine dateien in irgendwelche schwachsinningen "datenpakete" auffriemeln und am anderen ende dann wieder zusammenbauen, wie es 9/10 leuten machen, die tcp nicht gechecked haben. kann man ya auc hhier im forum immer wieder beobachten

If no buffer space is available within the transport system to hold the data to be transmitted, send will block unless the socket has been placed in nonblocking mode. On nonblocking stream oriented sockets, the number of bytes written can be between 1 and the requested length, depending on buffer availability on both the client and server computers.