SQLite Server

[tabellar]

Hm, der vorige Beitrag von mir war wohl zu lange für das Forum und hat mich rausgeschmissen ...

Tabellar

[Leonidas]

Ich werd mir xmpppy mal anschauen. Jabberpy ist nunmal ausgereift und wird z.B. in "Programming Jabber" (O'Reily) verwendet. Ich verwende unseren privaten "JabberServer", der nur über SSL (443) erreicht werden kann. Den amessage Server verwende ich z.B. im Zusammenspiel mit FreeMind, damit ist in der derzeitigen Version Collaboration via Jabber Protokoll möglich.

Ich weiß, jedoch ist xmpppy eine Wieterentwicklung von Jabberpy, die die API so weit wie möglich beibehlaten möchte. In wie weit das gelungen ist, kann ich nicht beurteilen. Aber der Autor von xmpppy ist auch Entwickler bei Jabberpy.

Wie gesagt, ich wollte Euch mal meine Gedanken und Tests mitteilen. Ich bin gerade eben an einem Thema dran, wo die Themen des Zugriffs und der Schnittstellen eher zweitrangig sind. Da muss ich erst noch ganz andere Dinge intern knacken. Ich sehe das ganze so, dass die Schnittstellen, egal ob Socket Verbindung (asynchore), Datei oder Jabber Schnittstellen eben NUR Interfaces sind. Es gibt dann eben trotzdem diverse andere interen Komponenten wie zB. einen Db (SQLite) Wrapper, Session oder Eventhandler, die dann die EIGENTLICHE Arbeit machen. Mit der angesprochenen Jabber Schnittstelle konnte ich eben sehr schnell mit einem Standard Jabber Client (JAJC, Exodus) auf den laufenden Pseudo Prototyp Server "internetweit" zugreifen. Ich seh ob er läuft (online) ist und entsprechende Meldungen oder Logs postet er mir an den entsprechenden Jabber Client, mit dem ich irgendwo im Internet angemeldet bin...

Sicher, eine Klasse Idee. Jedoch gebe ich zu, dass ich mich mit der programmierung von Jabber-Programmen nicht auskenne.

Also, um unabhängig zu sein, ist natürlich eine Lösung mit asynchore ideal. Hat man einen eigenen Jabber Server, kann man von dem die Dienste für die connections und die Userverwaltung der einzelnen "Agents" verwenden. Gerade bei der Agenten Entwicklung finde ich SQLite ideal, da es sehr klein und leistungsfähig ist und nicht unbedingt ein grosser Datenbank Server sein muss.

Klar, aber dazu bräuchte man doch einen Jabber Server. Und wenn ich einen SQL Server brauche, dann sollte es doch keine Vorraussetzung sein, dass ich einen Jabber Server habe. VOr allem Erfordert ein Jabber Server natürlich auch wieder Administration.

Eine gscheite und gschickte Lösung ist natürlich immer gut und natürlich anzustreben...

Gut. Ich habe mir auch noch folgendes überlegt:

- Ein Kern (muss keine Netzwerkfähigkeiten beinhalten, sondern nur das bereitstellen was alle Transports brauchen (könnten), wie zum Beispiel eine Userdatenbank mit jeweiligen Rechten)
- Transports (greifen auf Kern zu, haben dort praktisch Superuserrechte, also dürfen sie alles und sie erlauben hat den Benutzern den Zugriff, oder eben nicht).
- Sonstiges: Vielleicht kann man die Userverwaltung auch noch auskoppeln.

Ich weiß, das habe ich schon mal angedeutet, aber jetzt etwas genauer.

Jetzt bleibt die Frage, wie greifen die Transports auf den Kern (oder das "Sonstige") zu:
Man könnte mit Threads und sowas wie Candygram arbeiten, das kann aber dank Threads kompliziert und fehleranfällig werden. Oder die Transports sind per sowas wie Pyro angeschlossen, aber dann müsste man die Geschwindigkeit dieser Lösung erstmal untersuchen.

[tabellar]

Gut. Ich habe mir auch noch folgendes überlegt:

- Ein Kern (muss keine Netzwerkfähigkeiten beinhalten, sondern nur das bereitstellen was alle Transports brauchen (könnten), wie zum Beispiel eine Userdatenbank mit jeweiligen Rechten)
- Transports (greifen auf Kern zu, haben dort praktisch Superuserrechte, also dürfen sie alles und sie erlauben hat den Benutzern den Zugriff, oder eben nicht).
- Sonstiges: Vielleicht kann man die Userverwaltung auch noch auskoppeln.


Jetzt bleibt die Frage, wie greifen die Transports auf den Kern (oder das "Sonstige") zu:

Wir kommen langsam an den Punkt, an dem ich gerade rumhirne ... Ich hab mit Deinem Namen "Transports" noch etwas Mühe... Aber der Reihe nach ... Ich orientiere mich bei meinem Thema zur Zeit stark an den Serverarchitekturen von Jabber und Asterisk (VoIP PBX). Die beiden Server sind äusserst flexibel in der Architektur ausgelegt und haben meiner Meinung nach eine grosse Zukunft vor sich. Beide Server haben das Hauptthema Kommunikation im weitesten Sinne.

Wenn ich den Vergleich hier ziehe, dann würde es so aussehen, dass wir hier sogenannte Service Komponenten und ein Transport Backbone haben . Auf dem Transport Backbone werden Nachrichten zwischen den einzelnen Services ausgetauscht.

Services wären also wie folgt:
- Data Manager
- User Manager
- client to server (c2s)
- Log Komp.

Transport Backbone [Kern]:
- Message Switch/Router
- Event Manager
- ...

Die Leute beim Jabber Projekt haben sich gesagt, warum das Rad nochmal erfinden? Aus diesem Grunde haben sie ihr Jabber Protokoll in XML implementiert, welches für die interne und externe Kommunikation verwendet wird. Der neue Jabberd2 Server ist sogar so stark skalierbar ausgelegt, dass alle internen ServiceComponents via TCP Sockets verbunden sind. Bei starker Last können somit einzelne ServComp auf andere Rechner "ausgelagert werden (zB. DB ServComp). Bei Asterisk wird der Nachfolger vom IAX2 (VoIP) Protokoll (-> XIAX) ebenfalls in XML implementiert sein.

Beim Überfliegen von Pyro habe ich gesehen, dass es auch ein ähnliches Transport Backbone zur Verfügung stellt. Bei meinem derzeitigen "Server-Prototypen" habe ich eben auch das XML Nachrichten Format zwischen den Services gewählt und bin damit sehr zufrieden. Alle XML Messages werden in der DB gespeichert und durch entsprechende Message/Event Bindings weiter geroutet (zur Zeit mit SQLite ). XML ist sehr flexibel und plattform- und programmiersprachenneutral.

Also, die Hauptknacknuss ist die Transportschicht zwischen den Services. Wie flexibel muss sie sein, wie schnell, wie stabil, DB Logging? Fremdmodule?

Gruss Tabellar

[tabellar]

Noch eine kurze Ergänzung: Wenn man das ganze natürlich rein unter dem SQL Server Aspekt sieht, dann wäre der Ablauf natürlich so, dass eigentlich ein Modul wie "PySQLite2" auf den "SQLator" zugreift und somit eine DB API 2.0 Schnittstelle darstellt... Das wäre das klassische (Python) Vorgehen...

Tabellar

[Leonidas]

Services wären also wie folgt:
- Data Manager
- User Manager
- client to server (c2s)
- Log Komp.

Transport Backbone [Kern]:
- Message Switch/Router
- Event Manager
- ...

Das ist natürlich eine tolle Sache, nur wird sowas schnell kompliziert und je komplizierter, desto schwieriger und aufwendiger zu implementieren. Und Anfällig wird sowas auch gerne.

Also, die Hauptknacknuss ist die Transportschicht zwischen den Services. Wie flexibel muss sie sein, wie schnell, wie stabil, DB Logging? Fremdmodule?

Naja, die Transportschicht wäre, wenn alle Services auf einem Server laufen, recht stabil. Also mit der flexibilität sollte man auch nicht übertreiben, denn man kann sie ja erweitern, das ist das tolle an Python. Fremdmodule sind zu vermeiden (besonders C-Erweiterungen), aber wenn sie viel helfen ist das auch in Ordnung.

[tabellar]

Das ist natürlich eine tolle Sache, nur wird sowas schnell kompliziert und je komplizierter, desto schwieriger und aufwendiger zu implementieren. Und Anfällig wird sowas auch gerne.

Also, die Hauptknacknuss ist die Transportschicht zwischen den Services. Wie flexibel muss sie sein, wie schnell, wie stabil, DB Logging? Fremdmodule?

Naja, die Transportschicht wäre, wenn alle Services auf einem Server laufen, recht stabil. Also mit der flexibilität sollte man auch nicht übertreiben, denn man kann sie ja erweitern, das ist das tolle an Python. Fremdmodule sind zu vermeiden (besonders C-Erweiterungen), aber wenn sie viel helfen ist das auch in Ordnung.

Mit "Transportschicht" habe ich nicht unbedingt damit gemeint, dass die Services auf unterschiedlichen Rechnern laufen, sonder wie der Aufruf von Funktionen innerhalb des Programmes gehandelt wird. Sprich, ob hard codiert oder "etwas flexibler". Also gut, bleiben wir einfach .

Mich würde eine "Server Schnittstelle" mit asyncore interessieren. Das kann auch ruhig in Richtung SimpleAsyncHTTP Modul gehen... Funktioniert das Senden und Empfangen von "Client Daten", könnte man PySqlite2 als DB API dazwischen schalten (wie Du es ja bereits beim SQLator v0.0.0.1 schon gemacht hast). Bei Bedarf kann dann ein Programm Paket integriert werden, das die User- und IP Verwaltung übernimmt, z.B. in separaten Tabellen oder in einfachen Text (XML) Files.

Programmteile:
- client/Server Paket (asyncore)
- Kern / Main Paket
- pysqlite2 DB API 2.0 Modul
- user/ip Paket

Hast Du schon asyncore Erfahrungen?

Gruss Tabellar

[Leonidas]

Hast Du schon asyncore Erfahrungen?

Nein, aber ich vermute das wäre auch ein Fall für asynchat.
Ich könnte schon etwas testen, jedoch habe ich mit Netzwerkprogrammierung "am socket" eher schlechte Erfahrungen gemacht.. warscheinlich bin ich zu doof dafür.

[tabellar]

Die Sache hat mir keine Ruhe gelassen. Ich glaub, wir haben jetzt die kleinste und einfachste Form eines TCP-Socket Deamons :

Weitere Schritte:
- Sessionhandling für einzelne Clientanfragen
- Erhöhung des Buffers für Datenübertragungen > 1024 --> [erledigt]
- User Authorizierung
- Command Line Interface (CLI) Befehlssatz festlegen
- Erhöhung der Funktionalität des SQLatorD -> select, asyncore, asynchat, etc.


[SQLatorD]

Code: Alles auswählen

#!/usr/bin/env python
# -*- encoding: latin-1 -*-
"""SQLatorD - the SQLator daemon
2005-06-24: A quick dirty TCP-Socket server for SQLite by Tabellar
2005-06-13: A XML-RPC server for the SQLite database by Leonidas
"""

import socket
from pysqlite2 import dbapi2 as sqlite

class SQLator(object):
   def __init__(self):
       self.port=8082
       self.dbfile="testdb.sqlite"
       try:
         self.con=sqlite.connect(self.dbfile)
         print "SQLiteDB '" + self.dbfile + "' connected..."
       except:
         print "SQLiteDB " + self.dbfile + " connection failed..."

   def run(self):
       """---"""
       self.run=1
       self.sock=socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
       self.sock.bind(("",self.port))
       print "SQLatorD waiting on port:", self.port
       
       while self.run:
           data,addr = self.sock.recvfrom(1024)
           #addr=Tupel ("text",portnr)         
           try:
             result=self.sqlExecute(data)
             print str(result)
             self.sendData(str(result),addr)
           except:
             print "Abfragefehler..."
             self.sendData("Abfragefehler...",addr)
     
   def sqlExecute(self,sql):
       cur=self.con.cursor()
       cur.execute(sql)
       resultList=cur.fetchall()
       self.con.commit()
       return resultList

   def sendData(self,data,addr):
       BUFSIZE = 1024
       while data:
             self.sock.sendto(data[:BUFSIZE], addr)
             data = data[BUFSIZE:]

def main():
    sqls=SQLator()
    sqls.run()

if __name__ == '__main__':
    main()



[SQLatorC]

Code: Alles auswählen

#!/usr/bin/env python
# -*- encoding: latin-1 -*-
"""SQLatorC - the SQLator client
2005-06-24: A TCP-Socket client for the SQLator Daemon by Tabellar   
2005-06-13: A client for the SQLator Daemon, for using SQLite over network by Leonidas
"""

import socket,sys

port = 8082
host = "localhost"
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.bind(("", 0))

intro = """SQLator remote shell
Enter ".help" for instructions"""

def dotparse(command):
    if command == 'quit':
        s.close()
        sys.exit()
    elif command == 'help':
        help()
    else:
        print 'No such command'

def help():
    helptext = {'.help' : 'Show this message',
        '.quit' : 'Exit this program'}
    for key in helptext.keys():
        print key, helptext[key]
    #print textwrap.wrap(helptext)

def sendQuery(query):
    s.sendto(query, (host, port))
    data=''
    BUFSIZE=1024
    while BUFSIZE==1024:
          sockData=s.recv(1024)
          data=data+sockData
          BUFSIZE=len(sockData)
    return data


def main():
    print intro
    while True:
        query = raw_input('sqlator> ')
        if query.startswith('.'):
            # parse, without the dot
            dotparse(query[1:])
        else:
            print sendQuery(query)


if __name__ == '__main__':
    main()

   

C:\Programme\sqlator>SQLatorD.py
SQLiteDB 'testdb.sqlite' connected...
SQLatorD waiting on port: 8082
[(1, None, 0, u'test Workflow', 1, 0)]
[(1, None, 0, u'test Workflow', 1, 0)]

Gentux1 root # python SQlatorC.py
SQLator remote shell
Enter ".help" for instructions
sqlator> select * from twfInst;
[(1, None, 0, u'test Workflow', 1, 0)]
sqlator>

Ich hätte nie gedacht, dass ich das mal hinbekommen würde ... Erste Tests mit Zugriff von Linux auf Win via LAN und Linux auf WIN via VPN funktionierten problemlos... und vor allem ist das ganze auch ganz schön schnell...

Grüsse Tabellar

EDIT:
- SQL Befehle "INSERT, etc." funktionieren (SQL query wird immer commited...)
- Datenpakete > 1024 Bytes können nun übertragen werden (Test 73kB)

[querdenker]

...Ich bin gerade an einem Thema dran, wo ich einen richtig schnellen, threadsicheren Server mit vielen DB Zugriffen brauchen könnte, aber natürlich in Python. Es geht um "Reaktive Systeme" (EventHandling) und "Workflowmanagement" und entsprechend vielen DB Zugriffen. Vielleicht mach ich dazu mal einen Thread in "Showcase" oder "Ideen" auf. Gibt's vielleicht den einen oder anderen Interessenten ? Ich würd mich freuen !!!

Tabellar

Bei der Geschichte melde ich mal Interesse an.
Und hab auch noch einen Vorschlag für die DB: FirebirdSQL
Wir haben das DB-System im Dauereinsatz, Installation ist sowohl unter Win* als auch unter Unix einfach und klein (ca 10 MB).
Und die Python-Seite ist mit KInterbasdb auch gut unterstützt.

mfg, querdenker

[tabellar]

Bei der Geschichte melde ich mal Interesse an.
Und hab auch noch einen Vorschlag für die DB: FirebirdSQL
Wir haben das DB-System im Dauereinsatz, Installation ist sowohl unter Win* als auch unter Unix einfach und klein (ca 10 MB).
Und die Python-Seite ist mit KInterbasdb auch gut unterstützt.

mfg, querdenker

Hallo querdenker,

freut mich, dass Du Interesse an der Geschichte hast . Was speziell würde Dich an den von mir genannten Themen reizen? Firebird habe ich mal eine zeitlang beobachtet, aber nie wirklich eingesetzt. Die DB für das Backend ist auch erst in zweiter Linie von Bedeutung. Wie sagte schon Leonidas: "First get it running. Then make it running good." Ich denke, dass ich die nächsten Tage mal das Projekt im "Ideen" Bereich vorstelle. Das ganze ist ziemlich umfangreich und komplex, aber macht unheimlich viel Spass...

Gruss Tabellar

[tabellar]

- SQLatorD kann jetzt Datenpakete > 1024 Bytes versenden.
- SQLatorC kann jetzt Datenpakete > 1024 Bytes empfangen.

Tabellar

[querdenker]

@tabellar:
Interesse besteht eigentlich in allen 3 Bereichen, d.h. EventManagment, Workflow und DB.

Magst du mir mal ein wenig mehr darüber erzählen?

mfg, querdenker

[tabellar]

@tabellar:
Interesse besteht eigentlich in allen 3 Bereichen, d.h. EventManagment, Workflow und DB.

Magst du mir mal ein wenig mehr darüber erzählen?

mfg, querdenker

@querdenker:
Im Ideen Bereich hab ich mal ein bisschen was geschrieben...

@Leonidas:
Beim SQLator würdest Du ja gerne die Socket Geschichte mit XML-RPC verbinden. Das würde aber auch bedeuten, dass der Server entsprechende "Objektmethoden" zur Verfügung stellen müsste. Wie und was würdest Du Dir da vorstellen?

Tabellar

[Leonidas]

Beim SQLator würdest Du ja gerne die Socket Geschichte mit XML-RPC verbinden. Das würde aber auch bedeuten, dass der Server entsprechende "Objektmethoden" zur Verfügung stellen müsste. Wie und was würdest Du Dir da vorstellen?

Ich würde vermutlich einfach mal draufloshacken und gucken was gerade nötig ist. Wenn ich mal wieder Zeit habe (und diese Woche ist ziemlich stressig) könnte ich mal versuchen einen Proof-of-Concept zu schreiben.

Ich weiß, das Vorgehen ist vielleicht nicht besonders sauber, jedoch denke ich, dass ich mich so am besten in die Anforderungen und Probleme einarbeiten könnte.

[tabellar]

Ich würde vermutlich einfach mal draufloshacken und gucken was gerade nötig ist. Wenn ich mal wieder Zeit habe (und diese Woche ist ziemlich stressig) könnte ich mal versuchen einen Proof-of-Concept zu schreiben.

Ich hab schon mal "etwas" vorgegriffen und eine einfache XML-RPC-Socket Version gebastelt : Der XML-RPC SQLator verfügt jetzt über eine Objektmethode "selectCurFetchAll", die abgerufen werden kann.

Code: Alles auswählen

#!/usr/bin/env python
# -*- encoding: latin-1 -*-
"""SQLatorD - the SQLator daemon
2005-06-30: A quick dirty XML-RPC Socket Server by Tabellar
2005-06-24: A quick dirty TCP-Socket server for SQLite by Tabellar
2005-06-13: A XML-RPC server for the SQLite database by Leonidas
"""

import socket
import xmlrpclib
from pysqlite2 import dbapi2 as sqlite

class SQLator(object):
   def __init__(self):
       self.port=8082
       self.dbfile="testdb.sqlite"
       try:
         self.con=sqlite.connect(self.dbfile)
         print "SQLiteDB '" + self.dbfile + "' connected..."
       except:
         print "SQLiteDB " + self.dbfile + " connection failed..."

   def run(self):
       """---"""
       self.run=1
       self.mainsock=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
       self.mainsock.bind(("",self.port))
       self.mainsock.listen(1) #max 1 Verbindung gleichzeitig
       print "SQLatorD waiting on port:", self.port
       
       while self.run:
           connection,address=self.mainsock.accept()
           print "Server connected by ",address
           while 1:
               data = connection.recv(1024)
               if not data: break
               print "received: ",data         
               params,method=xmlrpclib.loads(data)
               print "Method:",method
               print "Params:",params
           
               try:
                 if method=="selectCurFetchAll":
                    result=self.selectCurFetchAll(params)
                    response=xmlrpclib.dumps(((str(result[0])),(str(result[1]))),"selectCurFetchAll")
                    connection.send(response)
                 else:
                    connection.send("Methode nicht erkannt")

               except:
                 print "Abfragefehler..."
                 connection.send("Abfragefehler...")
           print "connection closed..."
           connection.close()

   def selectCurFetchAll(self,sqlquery):
       cur=self.con.cursor()
       cur.execute(str(sqlquery[0]))
       resultList=cur.fetchall()
       self.con.commit()
       return resultList


def main():
    sqls=SQLator()
    sqls.run()

if __name__ == '__main__':
    main()

Code: Alles auswählen

#!/usr/bin/env python
# -*- encoding: latin-1 -*-
"""SQLatorD - the SQLator daemon
2005-06-30: A simple quick dirty XML-RPC Socket Connection by Tabellar
"""

import socket
import xmlrpclib

#socket connection
port = 8082
host = "localhost"
con=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
con.connect((host,port))

#xml-rpc Input
Method="selectCurFetchAll"
Param=("select * from twfInst;")

#xmlrpclib "dumps"
request=xmlrpclib.dumps(((Param),),methodname=Method)

#xml-rpc-String
"""<?xml version='1.0'?>
<methodCall>
 <methodName>selectCurFetchAll</methodName>
  <params>
     <param>
       <value><string>select * from twfInstNode;</string></value>
     </param>
  </params>
</methodCall>"""

#Server XML-RPC Request
con.send(request)

#Server XML-RPC Response
data=con.recv(1024)

#xmlrpclib "loads"
param,method=xmlrpclib.loads(data)

#Print der Daten
print
print "Methode:", method
print "Input  :", Param
for i in param:
    print "Output :", i

#Connection schliessen
con.close()

C:\Programme\sqlator>RPCSQLatorC.py

Methode: selectCurFetchAll
Input : select * from twfInst;
Output : (1, None, 0, u'test Workflow', 1, 0)
Output : (2, None, 0, u'test', 123, 0)

Tabellar