Re: [Python-de] Dateien ueber Sockets uebertragen
Hi Am 31.03.2004 14:41:08 schrieb Hartmut Goebel:
Und warum nicht an die Liste? Ist dieses Problem so speziell dass es die Allgemeinheit nicht interessiert?
Ging an die Liste un an dich.
Oh tut mir leid, hatte das CC uebersehen. Aber wieso hab ich dann die Mail nicht auch ueber die Liste bekommen? *kopfkratz* Ich sende das jetzt mal per CC noch an die Liste, ich glaub da funktioniert was nicht ganz so wie es soll.
Kann es sein, dass Du vor der Schleife versehentlich schon etwas aus dem Socket liest, das Dir dann natürlich fehlt? Hast Du den Inhalt der geschriebenen Datei verglichen, wo die Daten fehlen?
Ich hab Analyzer (ein Sniffer) die Kommunikation belauschen lassen. Der Server nutzt folgenden Code zum Senden: self.connection.send('OK') self.connection.send(cPickle.dumps(file_size)) sendBytes = 0 while 1: data = file.read(self.BlockSize) if not data: break self.connection.send(data) sendBytes += len(data) print '%d - %d' % (file_size, sendBytes) "self.connection.send('OK')" erzeugt ein eigenes TCP-Packet so wie's sein soll. Problem ist, dass "self.connection.send(cPickle.dumps(file_size))" kein eigenes TCP-Packet erzeugt, stattdessen werden an das Packet die Daten vom darauffolgenden "self.connection.send(data)" angehängt. Und das sind auch genau die Daten die am Ende fehlen. Den Clienten scheinen beim "file_size = cPickle.loads(self.sockobj.recv (self.BlockSize))" die überzähligen Daten jedenfalls nicht zu stören, der wirft die mal ebend weg. Folgendes hilft auch nicht: temp = cPickle.dumps(file_size) self.connection.send(temp) Dieses send(temp) und das nachfolgende send(data) werden irgendwie miteinander vermanscht. Wie schon gesagt, lokal funktioniert alles, leider scheint Analyzer kein localhost zu kennen. thx & cu boesi -- Ein Wunder muss heute schon ganz schoen #1671 : icq-intern wundervoll sein um ein Wunder zu sein, #73628288 : icq-extern sonst wuerde man sich ja gar nicht mehr wundern boesi111 : aim .-==Prof. Dr. Harald Lesch==-. i171 : reallife _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Hi, Alexander 'boesi' Bösecke wrote:
Oh tut mir leid, hatte das CC uebersehen. Aber wieso hab ich dann die Mail nicht auch ueber die Liste bekommen? *kopfkratz*
Weil Du nicht über die Liste geantwortet hattest. :-) So, wir machen jetzt eine kleine Coaching, für das andere Leute 150 EUR die Stunde zahlen (leider nicht bei mir ;-). Beantworte dazu die folgenden Fragen: * Welche Daten fehlen _genau_? * Was kannst Du tun um dieses festzustellen? Was noch? (Sprich: Alternativen zum Sniffer) * Ist die schon das minimale Beispiel, bei dem der Fehler auftritt? * Was ist das maximale Beispiel, bei dem der Fehler nicht auftritt? * Welche Zeile(n) unterscheiden das Beispiel, bei dem der Fehler auftritt, von einem Beispiel, bei dem der Fehler nicht mehr auftritt? ... ... Erst nach Beantwortung der Fragen weiterlesen ... ... ...
Ich hab Analyzer (ein Sniffer) die Kommunikation belauschen lassen.
Und was ist das Ergebnis? Ich bezweifle, dass Du das was brauchbares sehen kannst, wenn Du gepickelte Daten verschickst. Benutze plain Text, das erleichtert die Arbeit -- auch wenn das Probelm dann erstmal nicht macht, was es soll.
Der Server nutzt folgenden Code zum Senden:
Irgendwie scheint mir da was zu fehlen. Für die Zunkunt: Bitte baue einen minimalen Server und einen minimalen Client, bei dem das Problem auftritt, und poste die beiden Quelltexte vollständig.
Den Clienten scheinen beim "file_size = cPickle.loads(self.sockobj.recv (self.BlockSize))" die überzähligen Daten jedenfalls nicht zu stören, der wirft die mal ebend weg.
Lies Dir nochmal durch, was Du da schreibst! Denn das ist doch genau die Lösung des Problems. Du liest 'blocksize' (Annahmen = 1024) Bytes, die unpickles Du und für unpickle sind nur die ersten vieleicht 5 Bytes interessant. Mit dem Rest weiß unpickle nichts anzufangen.
Folgendes hilft auch nicht: temp = cPickle.dumps(file_size) self.connection.send(temp) Dieses send(temp) und das nachfolgende send(data) werden irgendwie miteinander vermanscht.
Überlege nochmal scharf: Oben schreibst Du, dass unpickle die Daten wegwirft. Weshalb hoffst Du dann, das Problem beim _Empfang_ zu lösen, wenn Du beim _Senden_ eine Variable mehr benutzt? Sollten sich dann die übertragenen Daten ändern? Doch sicher nicht. Lösungsvorschläge (alles Skizzen, die dümmsten zuerst): 1) Beim Absender: data = self.sockobj.recv(self.BlockSize) # filesize lesen file_size = cPickle.loads(data) # Länge der zu gehörigen Daten ermitteln len_data = len(cPickle.dumps(file_size)) # abschneiden data = data[len_data:] 2) Beim Sender: self.connection.send(cPickle.dumps(file_size)) self.connection.send('\n') Beim Empänger: data = self.sockobj.recv(self.BlockSize) file_size, data = data.split('\n',1) file_size = cPickle.loads(file_size) 3) Beim Sender: self.connection.send('%s\n' % file_size) Beim Empänger: data = self.sockobj.recv(self.BlockSize) file_size, data = data.split('\n',1) file_size = int(file_size) 4) Und das schlage ich wirklich vor: Benutze SimpleHTTPServer oder BaseHTTPServer und du brauchst Dich um diese Probleme nicht zu kümmern. Der Vorteil von Standards ;-) Wenn Du komplexere Protokolle hast, wären die XMLRPC-Server auch eine gute Möglichkeit.
Wie schon gesagt, lokal funktioniert alles, leider scheint Analyzer kein localhost zu kennen.
Analyzer -> Tonne. BTW, welcher ist das? -- Regards Schönen Gruß Hartmut Goebel | Hartmut Goebel | IT-Security -- effizient | | h.goebel@goebel-consult.de | www.goebel-consult.de | _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Hi Ich hab mein Problem inzwischen zufriedenstellend geloest, aber ich antworte trotzdem mal, weil ich will ja was lernen :) Meine Loesung steht am Ende der Mail. Einiges von dem hier hatte ich bestimmt schon geschrieben... Am 02.04.2004 10:50:37 schrieb Hartmut Goebel:
Oh tut mir leid, hatte das CC uebersehen. Aber wieso hab ich dann die Mail nicht auch ueber die Liste bekommen? *kopfkratz*
Weil Du nicht über die Liste geantwortet hattest. :-)
Received: from localhost ([127.0.0.1] helo=starship.python.net) by starship.python.net with esmtp (Exim 4.30) id 1B9WMZ-0003y3-In; Fri, 02 Apr 2004 23:38:07 +0200 Received: from postman2.arcor-online.net ([151.189.0.152] helo=postman.arcor.de) by starship.python.net with esmtp (Exim 4.30) id 1B9KG6-0008Ex-JS for python-de@python.net; Fri, 02 Apr 2004 10:42:38 +0200 Bei 13 Stunden Verzoergerung wundert mich nicht mehr viel.
So, wir machen jetzt eine kleine Coaching, für das andere Leute 150 EUR die Stunde zahlen (leider nicht bei mir ;-).
Danke :)
* Was kannst Du tun um dieses festzustellen? Was noch? (Sprich: Alternativen zum Sniffer)
Das Daten fehlen, hab ich festgestellt, weil die uebertragene Datei nicht vollstaendig war. Um festzustellen welche Daten fehlen, hab ich ne Text-Datei uebertragen. Dabei hab ich dann festgestellt, dass immer der erste Teil fehlt Den Sniffer hab ich verwendet um zu sehen, wo die Daten geblieben sind und dabei festgestellt, dass diese ebend nicht fehlen, sondern nur im "falschen" Packet gelandet sind
* Was ist das maximale Beispiel, bei dem der Fehler nicht auftritt?
Remote trat der Fehler immer auf. Lokal gar nicht. Bzw ich weiss nicht, was du mit maximales Beispiel meinst.
* Welche Zeile(n) unterscheiden das Beispiel, bei dem der Fehler auftritt, von einem Beispiel, bei dem der Fehler nicht mehr auftritt?
Ein time.sleep(0.2) nach dem ersten send brachte Abhilfe, das war aber natuerlich keine Loesung
Ich hab Analyzer (ein Sniffer) die Kommunikation belauschen lassen.
Und was ist das Ergebnis? Ich bezweifle, dass Du das was brauchbares sehen kannst, wenn Du gepickelte Daten verschickst.
Also zb die Zeichenfolge "L30063L\n." im TCP-Packet kann ich sehr wohl als 30063L identifizieren. Allerdings scheint mir (c)Pickle wirklich nicht das geeignete Mittel um einfache Datentypen wie Integer, Listen und Tupel zu uebertragen. Oder spricht irgendwas gegen die Verwendungen von repr/eval?
Der Server nutzt folgenden Code zum Senden:
Irgendwie scheint mir da was zu fehlen. Für die Zunkunt: Bitte baue einen minimalen Server und einen minimalen Client, bei dem das Problem auftritt, und poste die beiden Quelltexte vollständig.
Ok werd mir Muehe geben.
Den Clienten scheinen beim "file_size = cPickle.loads(self.sockobj.recv (self.BlockSize))" die überzähligen Daten jedenfalls nicht zu stören, der wirft die mal ebend weg.
Lies Dir nochmal durch, was Du da schreibst! Denn das ist doch genau die Lösung des Problems.
Ja die Mail war Teil meines Denkprozesses, nur fertig gedacht hatte ich erst, als die Mail schon weg war :)
Du liest 'blocksize' (Annahmen = 1024) Bytes, die unpickles Du und für unpickle sind nur die ersten vieleicht 5 Bytes interessant. Mit dem Rest weiß unpickle nichts anzufangen.
Ja das ist mir auch aufgefallen, als ich mir die Doku zu cPickle angeschaut hab. Das kommt davon, wenn man annimmt, das Lesen eines Buches wuerde reichen um die Verwendung so eines Moduls zu lernen.
Lösungsvorschläge (alles Skizzen, die dümmsten zuerst):
Ich habs jetzt folgender Klasse geloest: class socking(socket): def __init__(self, family=AF_INET, type=SOCK_STREAM, BufSize=1024, proto=0, _sock=None): self.BufSize = BufSize socket.__init__(self, family, type, proto, _sock) self.getData = '' def putSock(self, data, FIL=0): if FIL == 1: typ = 'FIL' else: if type(data) == int: typ = 'INT' elif type(data) == long: typ = 'LNG' elif type(data) == str: typ = 'STR' elif type(data) == list: typ = 'LST' elif type(data) == tuple: typ = 'TPL' else: typ = 'OTH' data = repr(data) if FIL == 0: data = repr(data) sendData = '%d-%s-%s' % (len(data), typ, data) try: self.send(sendData) except: return 1 else: return 0 def getSock(self): length = 0 typ = '' data = '' while length == 0: index = self.getData.find('-') if index != -1: length = int(self.getData[:index]) self.getData = self.getData[index+1:] else: self.getData += self.recv(self.BufSize) while typ == '': index = self.getData.find('-') if index != -1: typ = self.getData[:index] self.getData = self.getData[index+1:] else: self.getData += self.recv(self.BufSize) while length != len(data): if length <= len(self.getData): data = self.getData[:length] if length < len(self.getData): self.getData = self.getData[length:] else: self.getData = '' else: self.getData += self.recv(self.BufSize) if typ != 'FIL': data = eval(data) return data def accept(self): sock, addr = self._sock.accept() return socking(BufSize = self.BufSize, _sock=sock), addr
4) Und das schlage ich wirklich vor: Benutze SimpleHTTPServer oder BaseHTTPServer und du brauchst Dich um diese Probleme nicht zu kümmern. Der Vorteil von Standards ;-)
Werde ich mir bei Gelegenheit sicher anschauen, aber meine Loesung gefaellt mir soweit ganz gut :) Bin aber natuerlich fuer jeden weiteren Vorschlag zu haben. Timeouts und Fehlerbehandlung fehlen noch, aber das hat im Moment eher geringe Prioritaet.
Analyzer -> Tonne. BTW, welcher ist das?
naja, nur weil ich zu bloed bin, mir da nen Filter fuer localhost zu bauen, wuerde ich den nicht gleich in die Tonne tun :) http://analyzer.polito.it/ thx & cu boesi -- --==SECURITY ALERT==-- #1671 : icq-intern Your Computer Is Currently Broadcasting An #73628288 : icq-extern Internet IP Address. With This Address, boesi111 : aim Someone Can Begin Attacking Your Computer. i171 : reallife _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Hi Hmpf grummel, ganz so einfach wars dann doch net.
Ich habs jetzt folgender Klasse geloest:
class socking(socket): [...] def putSock(self, data, FIL=0): [...] if FIL == 0: data = repr(data)
Diese Zeile ist natuerlich mehr als ueberfluessig. cu boesi -- --==SECURITY ALERT==-- #1671 : icq-intern Your Computer Is Currently Broadcasting An #73628288 : icq-extern Internet IP Address. With This Address, boesi111 : aim Someone Can Begin Attacking Your Computer. i171 : reallife _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Alexander 'boesi' Bösecke schrieb:
* Was ist das maximale Beispiel, bei dem der Fehler nicht auftritt?
Remote trat der Fehler immer auf. Lokal gar nicht. Bzw ich weiss nicht, was du mit maximales Beispiel meinst.
Ein "maximales Beispiel, bei dem der Fehler auftritt" ist das Beispiel, das gerade so komplex ist, dass der Fehler noch nicht auftritt. Die Idee dahinter ist, den Fehler von "oben" und "unten" einzugrenzen: Man iteriert sich quasi an den Fehler heran. Klar?
* Welche Zeile(n) unterscheiden das Beispiel, bei dem der Fehler auftritt, von einem Beispiel, bei dem der Fehler nicht mehr auftritt?
Ein time.sleep(0.2) nach dem ersten send brachte Abhilfe, das war aber natuerlich keine Loesung
Damit hast Du vielleicht einen word-around gefunden, aber das Problem nicht gelöst. Oder konntest Du danahc sagen: "Aha, daran war es gelegen"? (Ich überlege mich eben, ob ich eine Vorlesung: Fehlersuche in Programmen anbieten soll ;-)
Allerdings scheint mir (c)Pickle wirklich nicht das geeignete Mittel um einfache Datentypen wie Integer, Listen und Tupel zu uebertragen. Oder spricht irgendwas gegen die Verwendungen von repr/eval?
Ja: eval ist typischerweise ein Zeichen von schlechtem Code, da es sich in den meisten Fällen vermeiden läßt. Für den Lösungsweg, den Du unten gegangen bist, wäre es aber okay -- ich würde nur gleich einen anderen Lösungsweg gehen ;-) Allerdings machst Du unten -- nach meinem Geschmack -- viel zu viel per Hand. Ich würde dann noch eher eine Mischung aus Deinem vorherigen Ansatz machen: Daten Pickeln und deren Länge vornewegschicken. Was Du dazu brauchst, hast Du unten schon stehen, kannst aber 80% wieder rausnehmen, weil das Pickle für dich übernimmt.
Ich habs jetzt folgender Klasse geloest:
Hmmmm, zum Lernen okay, für produktiven Einsatz hat es einen Haken: Es löst ein Problem, für das es schon andere Lösungen gibt.
if FIL == 1: typ = 'FIL' else: if type(data) == int: typ = 'INT' elif type(data) == long: typ = 'LNG' elif type(data) == str: typ = 'STR' elif type(data) == list: typ = 'LST' elif type(data) == tuple: typ = 'TPL' else: typ = 'OTH' data = repr(data) if FIL == 0: data = repr(data)
Das kannst Du auch Pickle machen lassen, denn Pickle arbeitet auch nicht anders.
while length == 0:
...
while typ == '':
... Wenn Du Header und Daten mit einem anderen Zeichen trenntst, als die Header-Felder untereinander, dann brauchst Du nur eine Schleife: while not '\n' in self.getData: ... (kann man noch optimieren). -- Regards Hartmut Goebel | Hartmut Goebel | We build the crazy compilers | | h.goebel@crazy-compilers.com | Compiler Manufacturer | _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Hi Am 05.04.2004 20:51:33 schrieb Hartmut Goebel:
Ein time.sleep(0.2) nach dem ersten send brachte Abhilfe, das war aber natuerlich keine Loesung
Damit hast Du vielleicht einen word-around gefunden, aber das Problem nicht gelöst. Oder konntest Du danahc sagen: "Aha, daran war es gelegen"?
Deswegen ja auch "das war aber natuerlich keine Loesung" Und ausserdem ... hat sich eine gewisse Anwendung namens Word inzwischen als Synonym fuer work-around verbreitet? *g*
Ja: eval ist typischerweise ein Zeichen von schlechtem Code, da es sich in den meisten Fällen vermeiden läßt.
Naja vermeiden kann man verdammt viel. Aber ist eval von der Performance her denn so schlecht? Oder was sind konkrete Nachteile von eval? (also nicht nur auf mein aktuelles Problem bezogen)
Für den Lösungsweg, den Du unten gegangen bist, wäre es aber okay -- ich würde nur gleich einen anderen Lösungsweg gehen ;-)
Dazu faellt mir jetzt Perl ein - There's more than one way to do it. *g*
Allerdings machst Du unten -- nach meinem Geschmack -- viel zu viel per Hand. Ich würde dann noch eher eine Mischung aus Deinem vorherigen Ansatz machen: Daten Pickeln und deren Länge vornewegschicken.
Ok, hab deine Anmerkungen in die beiden Methoden eingearbeitet, die sehen jetzt so aus: def sendData(self, data, File=0): if File == 1: typ = 'F' else: data = cPickle.dumps(data) typ = 'P' self.sendall('%d-%s.%s' % (len(data), typ, data)) Den Typ F verwende ich fuer Daten, die Teil von Dateien sind, irgendwie find ichs albern die zu picklen. def recvData(self): while 1: # Header der Nachricht index = self.getData.find('.') if index != -1: length, typ = self.getData[:index].split('-', 1) length = int(length) self.getData = self.getData[index+1:] break self.getData += self.recv(self.BufSize) while 1: # Daten der Nachricht if length <= len(self.getData): data = self.getData[:length] if length < len(self.getData): self.getData = self.getData[length:] else: self.getData = '' break self.getData += self.recv(self.BufSize) if typ == 'P': data = cPickle.loads(data) # Konvertierung der Daten return data
(kann man noch optimieren).
Wenn du weitere Vorschlaege hast... thx & cu boesi -- A Achkatz'l ofm Baam #1671 : icq-intern des hot a schins Laam #73628288 : icq-extern braucht keen Pfenng Gald boesi111 : aim un freit sich of dr Walt i171 : reallife _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
"Alexander" == Alexander 'boesi' Bösecke <boesi.josi@gmx.net> writes: [...] Alexander> sendData = '%d-%s-%s' % (len(data), typ, data) Alexander> try: self.send(sendData) Alexander> except: return 1 [...]
Hmmm. Rein aus dem Gedächnis heraus, würde ich sagen, daß man besser self.sendall(sendData) sagen sollte. Falls sendData zu gross wird, wird Dir send() nicht alles schicken. Ausschnitt aus "pydoc socket": ,---- | sendall(data[, flags]) -- send all data | send(data[, flags]) -- send data, may not send all of it `---- Holger _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Hi Am 06.04.2004 21:48:32 schrieb Holger Duerer:
Hmmm. Rein aus dem Gedächnis heraus, würde ich sagen, daß man besser self.sendall(sendData) sagen sollte. Falls sendData zu gross wird, wird Dir send() nicht alles schicken.
Hab mir mal die Doku dazu angesehen. send und sendall unterscheiden sich lediglich in der Fehlerbehandlung. send gibt die Zahl der gesendeten Bytes zurueck, im Normalfall ist das halt len(sendData). sendall dagegen loest eine exception aus, wenn nicht alle Bytes gesendet werden konnten, es ist aber nicht moeglich zu erfahren wieviele Bytes gesendet worden. Es ist also Blödsinn send in try-except zu kapseln, und da ich ich im Moment noch keine Fehlerbehandlung einbauen will, kann/sollte ich sendall verwenden, damit ich Fehler ueberhaupt mitbekomm. cu boesi -- So stellt sich der Atheist doch die #1671 : icq-intern Unsterblichkeit vor - Lokalverbot #73628288 : icq-extern auf dem Friedhof. boesi111 : aim i171 : reallife _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
"Alexander" == Alexander 'boesi' Bösecke <boesi.josi@gmx.net> writes:
>> Hmmm. Rein aus dem Gedächnis heraus, würde ich sagen, daß man >> besser self.sendall(sendData) sagen sollte. Falls sendData zu >> gross wird, wird Dir send() nicht alles schicken. Alexander> Hab mir mal die Doku dazu angesehen. send und sendall Alexander> unterscheiden sich lediglich in der Fehlerbehandlung. Alexander> send gibt die Zahl der gesendeten Bytes zurueck, im Alexander> Normalfall ist das halt len(sendData). sendall dagegen Alexander> loest eine exception aus, wenn nicht alle Bytes Alexander> gesendet werden konnten, es ist aber nicht moeglich zu Alexander> erfahren wieviele Bytes gesendet worden. Also, auch auf die Gefahr hin, hier als Person dazustehen, die unbedingt das letzt Wort haben muß: Ich weiß nicht, in welcher Doku Du das nachgelesen hast, aber wenn Du es nicht falschverstanden hast, solltest Du sie wegwerfen, da da Mist drinsteht. pydoc socket sagt, daß sendall send aufruft, bis alle Daten gesendet wurden. Nur im Fehlerfall bekommst Du ne Exception und weißt nicht, wieviel gesendet wurde. Nach betrachten des Quellkodes halte ich diese Interpretation der Dinge für die korrekte und Deine für die inkorrekte Version. [...] Holger _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Alexander 'boesi' Bösecke schrieb:
Hi
Am 06.04.2004 21:48:32 schrieb Holger Duerer:
Hmmm. Rein aus dem Gedächnis heraus, würde ich sagen, daß man besser self.sendall(sendData) sagen sollte. Falls sendData zu gross wird, wird Dir send() nicht alles schicken.
Hab mir mal die Doku dazu angesehen. send und sendall unterscheiden sich lediglich in der Fehlerbehandlung. send gibt die Zahl der gesendeten Bytes zurueck, im Normalfall ist das halt len(sendData). sendall dagegen loest eine exception aus, wenn nicht alle Bytes gesendet werden konnten, es ist aber nicht moeglich zu erfahren wieviele Bytes gesendet worden. Es ist also Blödsinn send in try-except zu kapseln, und da ich ich im Moment noch keine Fehlerbehandlung einbauen will, kann/sollte ich sendall verwenden, damit ich Fehler ueberhaupt mitbekomm.
cu boesi
Auf die Gefahr hin, als Spielverderber angesehen zu werden, aber meine Mail ist jetzt die 20. Mail zu einem relativ einfachen Problem. Generell scheint hier ein Missverständnis über send() vorzuliegen. Es ist weder ein Fehler, wenn send() nicht alle Daten versenden kann, noch kann es als Normalfall angesehen werden, dass send() alle Daten auf einmal sendet. Im Extremfall könnten die Daten bytesweise versendet und empfangen werden. Eine Funktion zum Versenden von Daten sollte immer den Rückgabewert von send() berücksichtigen, und send() solange aufrufen, bis alle Daten versendet wurden. Das gleiche gilt natürlich für das Empfangen von Daten. Aufrufe von time.sleep() oder sonstige zeitintensive Aktivitäten haben in den Sende-/Empfangs-Funktionen nichts zu suchen, es sein denn, die Performance ist einem völlig egal. Solche Massnahmen wie Abschalten des Nagle-Algorithmus verbieten sich völlig, da Sie Einfluss auf die gesamte Netzwerkperformance haben können. Ulli _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
participants (6)
-
Alexander 'boesi' Bösecke -
Alexander 'boesi' Bösecke -
Hartmut Goebel -
Hartmut Goebel -
Holger Duerer -
ulrich.berning＠t-online.de