Python Server erstellen welche UDP und TCP kann

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:
> 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.