Hallo, ich habe mich ein bisschen mit Python beschäftigt. Dabei habe ich einen TCP Server/Client erstellt und die Verbindung gestestet. Hat funktioniert. Danach eine UDP Server/Client Verbindung. Tut auch. Das alles Lokal auf einem Rechner. Jetzt benötige ich einen Server, der beides kann. Sowohl TCP empfangen und quittieren und diese Daten bzw. je nach dem was für daten gesendet werden entsprechende daten per UDP an einen anderen Client senden. Geht das überhaupt bzw. gibt es dafür schon Lösungen? Grüße
:
Verschoben durch User
Das Framework der Wahl heisst 'Twisted', und ja da ist das kein Problem mit.
Sven schrieb: > ich habe mich ein bisschen mit Python beschäftigt. Dabei habe ich einen > TCP Server/Client erstellt und die Verbindung gestestet. Hat > funktioniert. > Danach eine UDP Server/Client Verbindung. Tut auch. Das alles Lokal auf > einem Rechner. > > Jetzt benötige ich einen Server, der beides kann. Sowohl TCP empfangen > und quittieren und diese Daten bzw. je nach dem was für daten gesendet > werden entsprechende daten per UDP an einen anderen Client senden. Das hört sich zunächst einmal nach einem merkwürdigen Design an. > Geht das überhaupt Ja, natürlich. > bzw. gibt es dafür schon Lösungen? Nicht, daß ich wüßte. Aber sowas mit Python zu schreiben, ist nicht schwer. Einfach die beiden Kommunikationskanäle in je einem eigenen Thread führen, über eine gemeinsame Datenstruktur die Daten zwischen den beiden austauschen und dabei das Locking nicht vergessen...
Sheeva P. schrieb: > Einfach die beiden Kommunikationskanäle in je einem eigenen > Thread führen, über eine gemeinsame Datenstruktur die Daten zwischen den > beiden austauschen und dabei das Locking nicht vergessen... Nein nein oh bloss nicht. 1000x lieber mit einem Event basiertem Ansatz loslegen und Threads vermeiden. Die produzieren nur Fehler die ein Anfänger nicht debuggen kann und ein Profi nicht debuggen will.
Florian F. schrieb: > Sheeva P. schrieb: >> Einfach die beiden Kommunikationskanäle in je einem eigenen >> Thread führen, über eine gemeinsame Datenstruktur die Daten zwischen den >> beiden austauschen und dabei das Locking nicht vergessen... > > Nein nein oh bloss nicht. > 1000x lieber mit einem Event basiertem Ansatz loslegen und Threads > vermeiden. Die produzieren nur Fehler die ein Anfänger nicht debuggen > kann und ein Profi nicht debuggen will. Ach Du liebe Güte. Multithreading und die Kommunikation zwischen Threads sind ja nun wirklich keine Raketenwissenschaft.
Florian F. schrieb: > Nein nein oh bloss nicht. > 1000x lieber mit einem Event basiertem Ansatz loslegen und Threads > vermeiden. Die produzieren nur Fehler die ein Anfänger nicht debuggen > kann und ein Profi nicht debuggen will. Wenn man keine Ahnung hat... In Python sind bestimmte Datenstrukturen der standard Module, im Gegensatz zu anderen Sprachen wie C++ mit der STL, von Werk aus Thread-Safe, z.B. Queues (sowohl queue.Queue als auch multiprocessing.Queue). aus dem queue-Modul:
1 | The queue module implements multi-producer, multi-consumer queues. |
2 | It is especially useful in threaded programming when information must |
3 | be exchanged safely between multiple threads. The Queue class in this |
4 | module implements all the required locking semantics. |
aus multiprocessing.Queue:
1 | Returns a process shared queue implemented using a pipe and a few |
2 | locks/semaphores. When a process first puts an item on the queue a |
3 | feeder thread is started which transfers objects from a buffer into |
4 | the pipe. |
Da ist nicht viel, wo man irgendwelche Fehler machen koennte "die ein Profi nicht debuggen will".
Und warum muss man dafür zwei Threads aufmachen? Gruss Chregu
Florian F. schrieb: > 1000x lieber mit einem Event basiertem Ansatz loslegen und Threads > vermeiden. Nein. Zwei sequentielle Abläufe die unabhängig voneinander ablaufen und sich vielleicht nur an einer ganz genau definierten Stelle berühren sind tausend mal leserlicher und fehlerfreier als zwei separate Threads hinzuschreiben und nachzuvollziehen als die beiden Abläufe in einer Statemachine in zig ineinander verschachtelte kleine Happen (Zustände und Übergänge) aufzuteilen und kreuz und quer in zufälliger Reihenfolge über den ganzen Quelltext zu verstreuen.
Christian M. schrieb: > Und warum muss man dafür zwei Threads aufmachen? Weils einfacher und übersichtlicher ist.
Christian M. schrieb: > Und warum muss man dafür zwei Threads aufmachen? Man muß nicht, man kann. Aber was spricht dagegen? Man könnte natürlich auch mit select(2), poll(2) oder epoll(7) arbeiten, das tut sich vom Aufwand und der Komplexität recht wenig. Aber je aufwändiger die Aufbereitung der Daten ist, desto sinnvoller wird es, sich durch Multithreading oder Multiprocessing zunutze zu machen, daß moderne CPUs mehrere Kerne haben -- da Multiprocessing allerdings eine Kommunikation zwischen unabhängigen Prozessen notwendig machen würde, wäre das ein bisschen aufwändiger.
:
Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.