Sockets
-
Hallo ich hätte da mal ne Frage!
Ich habe ein C Programm und ein C# Programm!
Das Programm ist mein Client und das C# der Server!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
-
tcp, udp oder was anderes?
wichtig ist, dass du den rückgabewert von 'recv' richtig interpretierst. dann klappt das schon.
-
Zu langsam? sicher nicht.
Wenn Du per TCP die Verbindung herstellst, dann sorgt das Protokoll dafür,
dass die Übertragung entsprechend "glatt" verläuft.
Entweder hast Du einen Fehler beim Senden oder beim Empfangen.
Kommen nur die ersten X Strings an und der Rest nicht oder lückenhaft?
-
Sorry txp verbindung!
Wie meinst du "richtig interpretierst"!Wieso bekomme ich aber nur die Hälfte der Strings? Würde ich es ja nciht richtig interpretiern würden ja garkeine ankommen odeR?
-
Es komen die ersten X Strings an!Aber vollständig..
THX
-
du hast tcp nicht verstande. du hast recv nicht verstanden.
-
Deine Aussage war sehr hillfreich
Was ist dann das Problem?
-
du bzw ddeine faulheit
-
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?
