@dannyboy385: Nur um Missverständnissen vorzubeugen weil Du mehrfach von Paketen sprichst: TCP ist ein Datenstrom und kennt erst einmal keine Datenpakete. Wenn Du in diesem Datenstrom mehrere ”Pakete” voneinander unterscheiden können willst, dann must *Du* das im Programm eine entsprechende Struktur in die Daten bringen und beim versenden und empfangen selber dafür sorgen das die Grenzen dieser Pakete erkannt und berücksichtigt werden. Wenn du auf der einen Seite mehrfach 1024 Bytes in den Datenstrom steckst, dann heisst das nicht das die auch in solchen 1024 Byte Häppchen auf der anderen Seite ankommen. Da können pro Aufruf mehr oder weniger Daten abgerufen werden, die Grössenangabe bei `recv()` ist nur eine Obergrenze. Da kann im Extremfall auch bei jedem Aufruf nur ein Byte geliefert werden so dass man für 1024 Bytes an Daten die mit einem `sendall()` auf die Reise geschickt wurden 1024 mal ``sock.recv(1024)`` aufrufen muss und jedes mal nur ein Byte bekommt. Auch wenn dieser Extremfall unwahrscheinlich ist, so muss robuster Socket-Code auch mit so einer Situation umgehen können.
An der Stelle versagen leider auch viele Bücher oder Socket-Beispiel-Code von Leuten die nur mal schnell Sockets zeigen wollen, aber von dem Thema nicht so viel Ahnung haben. Man findet leider viele schlechte, weil kaputte, Beispiele. Nicht nur im Netz, sondern auch in so einigen Büchern.
Noch ein Tipp um Fehlermeldungen zu zeigen: Schreib die nicht ab sondern kopiere sie, denn wenn Dein System tatsächlich „brocken pipe“ meldet, dann ist es wohl ziemlich „brocken“, äh pardon, *broken*.
Was die Programme angeht: Du bist in beiden Beispielen inkonsequent was Schreibweisen angeht, als wenn Du aus zwei verschiedenen Quellen kopiert hättest. Grundsätzlich kann ein Blick in den
Style Guide for Python Code nicht schaden. Namen sollte man nicht durchnummerieren was bei `s1` gar keinen Sinn macht und bei `socket1` nur in sofern als das man sich damit den Namen des Moduls nicht verdeckt. Da verwenden die meisten Module allerdings den Namen `sock` als Ausweg. Ist zwar nicht wirklich schön, aber üblich.
Der Kommentar im Client steht so überhaupt nicht in der Nähe der Codezeile die dann tatsächlich das macht was im Kommentar steht. Würde er dort stehen, wäre er überflüssig, denn das sieht man ja schon am Code selber. Kommentare beschreiben üblicherweise nicht *was* Code macht, denn dafür hat man ja schon den Code, sondern *warum* er das so macht wie er es macht. Und das auch nur wenn das nicht offensichtlich ist. Wobei man dabei durchaus von einem halbwegs kompetenten Programmierer ausgehen sollte bei der Entscheidung was offensichtlich ist und nicht von einem absoluten Anfänger.
Python hat spezielle Wahrheitswerte (`True` und `False`) die man auch verwenden sollte anstatt von Zahlen.
Die Client hat das besagte Datenstrom-Problem. Das `recv()` muss nicht alle Daten liefern die der Server gesendet hat. Es kann sein dass man das mehrfach aufrufen muss. Gleiches gilt für den Server.
Die Bedingungen bei ``while`` & Co gehören nicht in überflüssige Klammern gesetzt.
Für das beschriebene Dateiübertragungsproblem würde ich von den Sockets Dateiobjekte abfragen — die haben da eine Methode für — und dann die passenden Funktionen aus dem `shutil`-Modul für das Kopieren verwenden. Wenn da mehr als eine Datei über eine Verbindung gehen soll, zum Beispiel vorher der Dateinamen, dann müsstest Du Dir ein Protokoll ausdenken und implementieren. Oder das mit den Low-Level-Sockets sein lassen und etwas existierendes verwenden.
``%`` ist ein binärer Operator dessen Bedeutung wie bei allen Operatoren von den beteiligten Datentypen der Operanden abhängt. Bei Zahlen ist es beispielsweise die Modulo-Operation, die sinnvoll ist, wenn sie sinnvoll ist. Und bei Zeichenketten die mittlerweile etwas veraltete Zeichenkettenformatierung, die durch die `format()`-Methode abgelöst wurde. Beides hätte man in der Python-Dokumentation nachlesen können. Das Tutorial dort und die Referenz zu den grundlegenden Typen sollte man irgendwann einmal durchgearbeitet haben. Um die Grundlagen kommt man nicht herum.