Sockets
-
Das hat nichts mit Faulheit zu tun!
Entweder gib gescheite Kommentare ab oder lass sie ganz bitte!
MFG
-
JustMe01 schrieb:
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.
-
fricky schrieb:
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!
-
JustMe01 schrieb:
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.
-
JustMe01 schrieb:
Ich habe jedoch die Vermutung, dass nicht alle Daten richtig empfangen werden!
überprüf's doch damit: http://www.simplecomtools.com/tcptesttool.html
-
Äh, Sorry lieber OP, aber das Problem ist mit an Sicherheit grenzender Wahrscheinlichkeit wirklich dass du die Sockets API nicht verstanden hast.
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.
-
hustbaer schrieb:
@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.
-
hustbaer schrieb:
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.
-
tut er auch IMMER
-
hustbaer schrieb:
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
-
Kannst du mir einen Link zu einer Doku geben wo dieses "garantierte Verhalten" auch dokumentiert ist?
-
manpage, msdn, et cetera
-
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.
