Hallo Leute,
ich versuche eine TCP Verbindung zwischen server und client zu bauen.
Der Client soll so schnell wie möglich senden.
Die Verbindung brecht ab wenn ich in der client-Seite keine
sleep(1)-funktion benutze, und ich bekomme die Meldung "Connection reset
by peer". Wie kann ich diese Fehler korrigieren ohne sleep zu benutzen.?
Ich bedanke mich schon mal für euere Hilfe.
Grüße,
Carolin
zwieblum hat Recht.
Mit dem restlichen Code wird es aber auch nicht gehen, weil recv()
meines wissens nicht wartet, bis eine Nachricht zum Lesen da ist.
D.h. wenn der Sender auch nur einmal nicht nachkommt, liefert recv()
gleich 0 und der Server macht ein close(); für den Client ist das
dann der "reset by peer".
break; // receive would block, not very interesting
69
}
70
}
71
}
Selbiges senderseitig.
Gerade bei Netzwerksachen ist das Auswerten der Return und Fehlercodes
eines der Dinge, die Licht ins Dunkel bringen können und auf die man nie
verzichten sollte. Manchmal muss man auch die Fehlercodes senderseitig
und empfängerseitig in der zeitlich richtigen Reihenfolge sehen, um
rauszukriegen was da warum falsch gelaufen ist.
Auf dieses Feature zu verzichten, bedeutet das Stochern im Nebel dem
Arbeiten bei gutem Licht vorzuziehen.
Hi, dass Du "connection reset by peer" als Fehler bekommst ist seltsam.
Das riecht nach Firewall oder dergleichen. Um so wichtiger ist es
tatsächlich mal alle Netzwerk-I/O-relevanten Aufrufe wie von Karl heinz
Buchegger vorgeschlagen mit einer vollständigen und korrekten
Fehlerbehandlung zu verbrähmen, so dass man die Fehlerursache ggf. nach
dem Ausschlussverfahren finden kann.
(Allerdings verstehe ich Karl heinz's switch()-Konstrukt nicht... IMHO
reicht doch perror("read") oder dergleichen.)
Funktioniert Dein Code denn, wenn Client und Server lokal auf ein und
demselben Rechner laufen und auf diesem Rechner sämtliche
möglicherweise störenden Komponenten wie Firewall (auch die von einer
möglichen Antivirus-Software) und andere Netzwerksauereien (ich denke da
an all das was neben klassischem Firewalling sonst noch mit iptables
machbar ist) abgeschalten sind?
Eine andere Möglichkeit, die mir noch einfällt, ist die falsche
Verwendung von close(2) oder die irrtümliche Verwendung von close(2)
statt shutdown(2). Allerdings bin ich mir da nicht sicher, ob man dann
"connection reset by peer" als Fehler beim Senden/Empfangen bekommen
würde (eigentlich hätte ich auf einen anderen Fehler getippt).
> Der Client soll so schnell wie möglich senden.
Es gibt eine Reihe von Dingen die dazu beachtet werden sollten. Los
gehts mit diversen Socket-Options (TCP_CORK, TCP_NODELAY, SO_xxxBUF
fallen mir spontan ein), weiter über Blocking I/O vs. Async IO,
select(2) vs. epoll(2) vs. sonstwas(X) bis hin zu Einstellungen, die
global für das gesamte System vorzunehmen sind (Stichwort sysctl).
Stephan
Klaus Wachtler schrieb:
> Mit dem restlichen Code wird es aber auch nicht gehen, weil recv()> meines wissens nicht wartet, bis eine Nachricht zum Lesen da ist.
Doch. Es sei denn der Socket wurde explizit auf nonblocking umgestellt.
Hallo,
ich bedanke mich für euere Antworte. Ich habe den Fehlercode ausgewertet
wie Karl heinz Buchegger geschrieben hat, und ich bekomme in
Empfänge-Seite diese Meldung nach ein mal empfangen:
s is not a socket descriptor.
: Socket operation on non-socket
Falls diese Information helfen kann:
Socket ist auf blocking mode
Sender und Empfänger laufen auf demselben Rechner
Carolin Zapa schrieb:
> s is not a socket descriptor.> : Socket operation on non-socket
Und das ist dir nicht deutlich genug? Was auch immer das ist, was du dem
Aufruf übergibst, es ist kein korrekt und erfolgreich geöffneter Socket.
Also liegt das Problem möglicherweise davor, wo der Socket herkommt,
oder er wurde zwischenzeitlich wieder geschlossen.
A. K. schrieb:
> Carolin Zapa schrieb:>>> s is not a socket descriptor.>> : Socket operation on non-socket>> Und das ist dir nicht deutlich genug? Was auch immer das ist, was du dem> Aufruf übergibst, es ist kein korrekt und erfolgreich geöffneter Socket.> Also liegt das Problem möglicherweise davor, wo der Socket herkommt,> oder er wurde zwischenzeitlich wieder geschlossen.
Ja. Das ist mir auch klar dass der Socket geschlossen wurde. Aber Es ist
mir noch nicht klar wieso der geschlossen wurde und wo wird es gemacht?
Wieso kommt das Problem nicht wenn ich in Sender-Seite ein
Sleep-Funktion rufe.
Carolin Zapa schrieb:
> Ja. Das ist mir auch klar dass der Socket geschlossen wurde. Aber Es ist> mir noch nicht klar wieso der geschlossen wurde und wo wird es gemacht?
Dann wirf in deinen (zum größten Teil hier unbekannten) Code noch ein
paar zusätzliche printf rein, die dir sagen, was in welcher Reihenfolge
gemacht wird.
Debuggen ist zwar eine Kunst für sich, aber zumindest die Idee überall
printf reinzugeben, damit einem das Programm mitteilt was es gerade
macht, sollte eigentlich ziemlich naheliegend sein.