Datenserver Designfrage

Sockets, TCP/IP, (XML-)RPC und ähnliche Themen gehören in dieses Forum
Antworten
george
User
Beiträge: 109
Registriert: Mittwoch 11. Januar 2006, 20:28
Wohnort: Berlin

Hey,

ich habe als neue Aufgabe die Programmierung eines Datenservers bekommen. Dieser soll als Background-Task laufen und in einem einstellbaren Intervall(z.B.25ms) elektronische Messgeräte pollen.

Ich würde ganz gerne in diesem Thread ein paar Designfragen diskutieren.

1.) Ist Python als Programmiersprache geeignet für die Programmierung
eines Servers? Ganz wichtig ist hier der Zeitfaktor.
Ist eventuell eine andere Programmiersprache vorzuziehen?

2.) Welches Internetprotokoll würdet ihr wählen; UDP oder TCP/IP

Aus meiner Sicht ist aus zeitlicher Sicht UDP die bessere Alternative, da
TCP/IP(zwecks CSMA/CD) zu zeitintensiv ist.

Danke und greets
george
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

george hat geschrieben:in einem einstellbaren Intervall(z.B.25ms) elektronische Messgeräte pollen.
Hallo George!

Das sind schon ziemlich wenig Informationen, mit denen du uns hier fütterst. ;-)

Das Pollen im 25ms-Takt ist sicher eine Herausforderung, da 25ms ziemlich kurz ist und alles, was du sonst noch mit dem Ergebnis deiner Abfrage machen musst, in diesen 25ms auch noch erledigt werden muss.

Allerdings schreibst du nicht, was du mit den Daten machen möchtest. Sollen die Daten in eine Textdatei gespeichert werden? Sollen die Daten nur im RAM gehalten werden? Was machen die Clients mit den Daten? Holen sich die Clients die Daten auch alle 25ms ab? Soll immer nur der letzte Wert an die Clients ausgeliefert werden, oder die gesammelten Werte?

Ob das Kommunikationsprotokoll eine Rolle spielt, das kann ich nicht sagen, da ich nicht weiß, wie die Clients auf den Server zugreifen sollen. (wie oben bereits angesprochen)

Python ist sehr gut geeignet, um damit Serverprogramme zu schreiben. Je nach erforderlicher Geschwindigkeit, kann man zwischen mehreren Möglichkeiten der Datenübertragung wählen. Am Einfachsten ist sicherlich XMLRPC. Durch den XML-Overhead ist es aber in der Übertragung und beim Parsen nicht unbedingt schnell. Es genügt aber sicher, wenn du nur ein paar Anfragen pro Sekunde beantworten möchtest. JSON-RPC ist XMLRPC sehr ähnlich. Der größte Unterschied ist aber, dass der Overhead für die Datenübertragung geringer ist. Somit ist es auch ein wenig schneller.

Muss es wirklich schnell sein, dann kannst du direkt mit den Modulen ``socket``, ``asyncore`` oder ``asynchat`` arbeiten. Allerdings ist das auch um einiges komplizierter.

- http://www.python-forum.de/topic-5478.html
- http://docs.python.org/lib/module-socket.html
- http://docs.python.org/lib/module-SocketServer.html
- http://docs.python.org/lib/module-select.html
- http://docs.python.org/lib/module-asyncore.html
- http://docs.python.org/lib/module-asynchat.html

Die Genauigkeit der Timer hängt vom Betriebssystem ab. Unter Windows ist ``time.clock()`` ziemlich genau. Unter Linux ist es ``time.time()``. Siehe: http://www.python-forum.de/topic-6775.html

mfg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
george
User
Beiträge: 109
Registriert: Mittwoch 11. Januar 2006, 20:28
Wohnort: Berlin

Hallo Gerold,

danke für deine Antwort.
Allerdings schreibst du nicht, was du mit den Daten machen möchtest. Sollen die Daten in eine Textdatei gespeichert werden? Sollen die Daten nur im RAM gehalten werden? Was machen die Clients mit den Daten? Holen sich die Clients die Daten auch alle 25ms ab? Soll immer nur der letzte Wert an die Clients ausgeliefert werden, oder die gesammelten Werte?
An dieser Stelle bin ich mir noch nicht endgültig sicher.
Fest steht jedenfalls eins, die Daten sollen von mehreren Clients abrufbar sein und ich möchte, falls möglich, keine Messwerte verlieren.
Mit der Textdatei bin ich mir unsicher, klingt aber nach einer interessanten Idee. Ich überlege die Daten als "Ringspeicher" im RAM zu halten So sind mehrere Messwerte im RAM vorhanden und der letzte ist sehr leicht abrufbar. Eventuell kann man die Messwerte noch mit einem Zeitstempel versehen.
Das Hauptproblem aus meiner Sicht wird das Timing und die Synchronisation der Prozesse sein.

Die Clients werden unterschiedliche Funktionalität besitzen. Zu einem das die Messwerte live gemonitort werden, aber auch das Steuern der Geräte soll möglich sein.

Die Frage die sich mir stellt ist, wie kann ich die Prozesslast möglichst gering halten? Bedingt durch mehrere mögliche Clients die gleichzeitig Daten abholen sollen können, wird es wohl auf eine Multithreading-Programmierung hinauslaufen. Weil nach meinem Wissensstand für jede Server-Client-Verbindung einer Thread aufgebaut werden muss, damit der Server wieder eingehende Verbindungen erkennt und akzeptieren kann.

Hoffe, dass es jetzt ein paar mehr Informationen sind.

Danke und greets
george
dev
User
Beiträge: 49
Registriert: Montag 23. Januar 2006, 09:52
Kontaktdaten:

Hi george,
george hat geschrieben: ich habe als neue Aufgabe die Programmierung eines Datenservers bekommen. Dieser soll als Background-Task laufen und in einem einstellbaren Intervall(z.B.25ms) elektronische Messgeräte pollen.

[...]

1.) Ist Python als Programmiersprache geeignet für die Programmierung
eines Servers? Ganz wichtig ist hier der Zeitfaktor.
Ist eventuell eine andere Programmiersprache vorzuziehen?
Man kann mit Python auch zeitkritische Dinge machen, ich empfehle den Genuß dieser Präsentation. Aber wichtiger als die Frage nach der Sprache dürfte die Taktfrequenz deines Hosts sein, sollte das ein kleines embedded sytem sein, wirst Du da wohl eher Probleme bekommen.

Wie sprichst Du die Meßgeräte an? Lokal via USB/seriell? Oder über ein IP Protokoll?
george hat geschrieben:Bedingt durch mehrere mögliche Clients die gleichzeitig Daten abholen sollen können, wird es wohl auf eine Multithreading-Programmierung hinauslaufen. Weil nach meinem Wissensstand für jede Server-Client-Verbindung einer Thread aufgebaut werden muss, damit der Server wieder eingehende Verbindungen erkennt und akzeptieren kann.
Dem ist definitiv nicht so.

Ich mache solche Sachen sehr gerne mit Twisted - ganz ohne eigene Threads. ;-)

Zeitstempel an den Meßwerten sind auf jeden Fall eine gute Idee. Und sollte die Meßgeräteabfrage-Routine zu langsam sein, kannst Du diese ja immernoch in einen externen Collector, z.B. in C geschrieben, auslagern und von diesem dann die Werte einsammeln.

Ciao,
dev
george
User
Beiträge: 109
Registriert: Mittwoch 11. Januar 2006, 20:28
Wohnort: Berlin

Hallo dev,

danke für deine Antwort Werde mal in Ruhe deine Alternative(Twisted) ansehen. Wichtig ist für mich die Minimierung der Prozesslast und ich glaube, dass das ein interessanter Ansatz ist.
Wie sprichst Du die Meßgeräte an? Lokal via USB/seriell? Oder über ein IP Protokoll?
Die Messgeräte werden seriell über eine RS232/ RS485/ (zukünfig eventuell über USB) angesprochen. In den Messgeräten befindet sich ein Microcontroller. Für den Datenaustausch/Steuerung wurde von uns ein Protokoll implementiert.
Durch das Aufsetzen des Datenservers möchte ich ein größere Flexibilität und erweiterte Einsatzmöglichkeiten erreichen.

Danke und greets
george
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Hi George!

Ich habe mich da mal ein wenig gespielt: ;-)

server.py: http://gelb.bcom.at/trac/misc/wiki/Pyth ... uellcode01

client.py: http://gelb.bcom.at/trac/misc/wiki/Pyth ... uellcode01

Der Client kann mehrmals laufen. Das ist kein Problem. Die Auslastung auf meinem Computer war nicht/kaum messbar. Allerdings habe ich auch einen "Intel Pentium Dual Core - 3400 Mhz". Wie das bei schwächeren Geräten aussieht, dass musst du selber herausfinden. Getestet und entwickelt unter Windows XP. Ob es so auch unter Linux läuft, dass musst du selber herausfinden.

Falls dir irgendwann mal "XMLRPC" zu langsam sein sollte, dann würde ich es mit "Twisted" probieren, so wie es "dev" bereits vorgeschlagen hat. "Twisted" erspart dir das Gefummel mit dem "socket"-Modul.

mfg
Gerold
:-)
Zuletzt geändert von gerold am Mittwoch 13. September 2006, 16:05, insgesamt 1-mal geändert.
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
george
User
Beiträge: 109
Registriert: Mittwoch 11. Januar 2006, 20:28
Wohnort: Berlin

Hallo Gerold,

danke für die Arbeit die dur dir gemacht hast. Ist echt nett.
Werde es mal integrieren und dann die Prozesslast + Timing beobachten.

Danke und greets
george
Antworten