Forum: PC-Programmierung Python Server erstellen welche UDP und TCP kann


von Sven (Gast)


Lesenswert?

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
von Florian F. (flof3000)


Lesenswert?

Das Framework der Wahl heisst 'Twisted', und ja da ist das kein Problem 
mit.

von Sheeva P. (sheevaplug)


Lesenswert?

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

von Florian F. (flof3000)


Lesenswert?

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.

von Sheeva P. (sheevaplug)


Lesenswert?

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.

von Kaj (Gast)


Lesenswert?

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

von Christian M. (Gast)


Lesenswert?

Und warum muss man dafür zwei Threads aufmachen?

Gruss Chregu

von Bernd K. (prof7bit)


Lesenswert?

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.

von Bernd K. (prof7bit)


Lesenswert?

Christian M. schrieb:
> Und warum muss man dafür zwei Threads aufmachen?

Weils einfacher und übersichtlicher ist.

von Sheeva P. (sheevaplug)


Lesenswert?

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
Noch kein Account? Hier anmelden.