sockets: client soll bei datentransfer abbrechen können
-
hallo,
ich habe ein server und ein client programm die binare dateien austauschen!
um zu übeprüfen ob alles klar gegangen ist überprüfe ich die rückgaben
von recv und send...nur was ist wenn ich beim client abbrechen will? wie kann ich das dem server
sagen ohne die verbindung zu beenden?
(server sendet dateien zum client)muss der client immer extra eine rückgabe machen? wenn die rückgabe dann
z.b: .ende wäre - würde der server halt aufhöhren...aber geht das nicht irgendwie anders? denn wenn der client auch immer senden
würde - würde alles auch langsamer dauern oder?danke schonmal
Babelduo
-
Manche Protokolle haben für diesen Fall bestimmte Statusbytes. Wenn du deine Dateien auf Packete aufteilst und rüberschickst, dann solltest du nach jedem Packet von der Gegenstelle ein Kennzeichen bekommen, ob die Daten erfolgreich übertragen wurden. Wenn nicht, dann sendest du z. B. das Packet nochmal. Oder die Gegenstelle sendet sogar das Statusbyte für Verbindungsabbruch.
-
man könnte auch noch eine zweite Verbindung öffnen wo dann der Server einfach dem Client "lauscht". Wenn dieser was schickt dann wird entsprechend reagiert...
Z.b wenn der Client den Download abbrechen möchte schickt er über die andere verbindung "XYZ" rein. Oder "XZY" für "download" neubeginnen. Übrigens braucht man bei TCP nicht zu überprüfen "ob alles klar" ist, darum kümmert sich schon TCP.aber geht das nicht irgendwie anders? denn wenn der client auch immer senden
würde - würde alles auch langsamer dauern oder?die zweikanal methode hätte hier den Vorteil dass der Server nicht jedesmal nach dem Senden noch in den "Lauschmodus" gehen müsste und der Client nur dann sendet wenn er wirklich "muss".
-
@CDW
Das wäre natürlich auch noch eine Methode. So ist es übrigens beim FTP-Protokoll auch. Eine Verbindung regelt die Kommandos und die andere die Übertragung.Ob alles klar ist, musst du bei einem eigenen Protokoll trotzdem prüfen. Das TCP/IP Protokoll ist schließlich eine Schicht drunter :).
-
Ob alles klar ist, musst du bei einem eigenen Protokoll trotzdem prüfen
ich dachte eher der Fragesteller meint dass er nach jedem Senden und empfangen noch sowas wie prüfsummen überprüft (also ob ein Datenpacket vollständig und nicht defekt angekommen ist), dann ist das überflüssig da TCP es schon macht. Was man sonst in seinem Protokol implementiert das ist die Sache des Programmierers und macht durchaus bei verschiedenen Sachen Sinn. Aber z.B die reine Datenübertragung (also auch Zips und Fotos usw.
) funktioniert bei HTTP auch ohne zusätliche Überprüfungen recht zuverlässig
(Get /Daten.zip HTTP/1.0 - 200 OK =>Daten folgen, oder eben: XXX Error). Also vom Prinzip her (HTTP 1.0) kommt es ohne zwei
verbindungen aus. Aber für viele Probleme (Chat/File Transport Server) bietet sich eben die Lösung mit dem zweitkanal praktisch an.
Wobei: man muss auch nicht für jeden Client einenen eigenen zweiten Kanal öffnen => man muss sich nur vorher zu dem "eigenen" Protokol ein paar Gedanken machen.
-
CDW schrieb:
=> man muss sich nur vorher zu dem "eigenen" Protokol ein paar Gedanken machen.
Da bin ich ganz deiner Meinung :).