(HTTP) Server mit Qt4

**TheDodger** · 20-12-2010, 08:39

Zitat von TheDodger

Sooo ... ich habe ein kleines Proof-of-Concept am Start.
Ein Programm, welches einen TCP-Port aufreist und dort anfragen entgegen nimmt.
Eine simple GET-Anfrage funktioniert auch.

Ich stellt das mal Online download ...
Vielleicht kann das ja mal jemand gebrauchen / mir Tipps geben / helfen, etc. ...

**zenobic** · 21-12-2010, 17:13

Nur eine Anregung:

In "env" könnte man z.B. session_id's reinlegen.
Zur jeder SessionId, könnte man die zugehörigen Werte serialisiert (z.B. QTScript JSON encoded) in env oder auf dem Filesystem ablegen (Server) sowie Client als Cookie oder Parameter.

Dafür würde ich "env" von einer globalen Konfigdatei entkoppeln,
da es schon readConfiguration gab, habe ich einen kleinen Patch:

http://pastebin.com/7RgDEMGd

(Es muss wenn es dir gefällt, noch die Signatur der 2 Funktionen in der Headerdatei aktualisiert werden).

**TheDodger** · 21-12-2010, 20:31

Zitat von zenobic

Nur eine Anregung:

In "env" könnte man z.B. session_id's reinlegen.
Zur jeder SessionId, könnte man die zugehörigen Werte serialisiert (z.B. QTScript JSON encoded) in env oder auf dem Filesystem ablegen (Server) sowie Client als Cookie oder Parameter.

Dafür würde ich "env" von einer globalen Konfigdatei entkoppeln, da es schon readConfiguration gab, habe ich einen kleinen Patch:

http://pastebin.com/7RgDEMGd

(Es muss wenn es dir gefällt, noch die Signatur der 2 Funktionen in der Headerdatei aktualisiert werden).

Vielen Dank!
Das schau ich mir gleich (oder morgen früh) mal an!

'env' kommt noch aus einem etwas älterem Projekt, da sind unter Garantie völlig Sinnfreie Dinge mit drin.

Sobald der Server mehrere Statische Dateien ausliefern kann, werd ich das mal mit siege stressen.
Ich weiß nämlich überhaupt nicht, ob er mehrere Anfragen parallel abarbeiten kann

In dem Sinne ... wäre es eigentlich sinnvoll, das ganze Ding mit Threads zu realisieren, oder weniger?

[EDIT]
Dann würde das mit den Plugins und QPluginLoader aber nicht mehr so funktionieren, richtig?
So wie ich das ganze verstanden hab, muß ich, beim Einsatz von Threads, die Plugins mit QLibrary laden, auch richtig?

**zenobic** · 21-12-2010, 21:14

Zitat von TheDodger

Vielen Dank!
Sobald der Server mehrere Statische Dateien ausliefern kann, werd ich das mal mit siege stressen.
Ich weiß nämlich überhaupt nicht, ob er mehrere Anfragen parallel abarbeiten kann

In dem Sinne ... wäre es eigentlich sinnvoll, das ganze Ding mit Threads zu realisieren, oder weniger?

Ich konnte es mir nicht verkneifen schon zu benchmarken und muss sagen, mit der Statusseite performt es jetzt schon (auch parallel) gut (es gibt ja auch Projekte die auch weitere Seiten in diesem Stil "hardcoden").

Da sind aber noch einige QT Meldungen die ich mir nicht genauer angesehen habe.

Code:

ab -n 1000 -c 5 http://127.0.0.1:8081/index.html

**zenobic** · 23-12-2010, 10:58

Zitat von TheDodger

Vielen Dank!
In dem Sinne ... wäre es eigentlich sinnvoll, das ganze Ding mit Threads zu realisieren, oder weniger?

Mit fork ist es nicht nur einfacher, sondern soweit ich weiss auch stabiler, aber eben nicht performanter.
Wobei Performance auch mit I/O auf der Platte zu tun hat und somit die darunterliegenden Lowlevel/Kernelfunktionen eine grosse Rolle spielen.

Zumindest hörte ich, dass ein Apache2 (Standardkonfiguration) mit Threads abstürzen kann,
da ein Thread den Prozess lahm legen kann.
Ein forked Prozess nicht (Apache1 oder Apache2 mit pre-fork modul).

fork() gibt es soweit ich weiss nicht für QT, da es dies nicht plattformübergreifend gibt.

Jetzt ist es doch jeder Request ein Thread oder meinst du multithreaded (QtConcurrent) ?

**TheDodger** · 29-12-2010, 11:10

Ich hab mal eine aktuelle Version zum download auf den Server kopiert.

Fühlt euch frei ...

**jeebee** · 28-12-2010, 20:54

Also bei mir (nach dem Hinzufügen von 68 Zeilen Code

) segfaultet es nicht, aber die Semantik ist sowieso falsch... Alle deine Cache-Einträge zeigen auf das selbe Element, nämlich den private class-member r_cache... Dieser enthält immer den Inhalt des zuletzt gecachten Files.

Flicken z.B. so:

Code:

void RIPCache::insert( QString f, QByteArray d ) {

   RequestCache *r = new RequestCache();

   r->setFile( f );
   r->setData( d );

   Debug( QString( "  size bevore '%1'" ).arg( m_cache.size() ).toAscii() );
   
   m_cache.insert( f, r_cache );

   Debug( QString( "  size after  '%1'" ).arg( m_cache.size() ).toAscii() );
}

Schöner wäre, wenn die Argumente für die Cache-Items direkt im Konstruktor übergeben werden... (also RequestCache *r = new RequestCache(f, d); ).

**TheDodger** · 28-12-2010, 23:15

Zitat von jeebee

Also bei mir (nach dem Hinzufügen von 68 Zeilen Code

) segfaultet es nicht, aber die Semantik ist sowieso falsch... Alle deine Cache-Einträge zeigen auf das selbe Element, nämlich den private class-member r_cache... Dieser enthält immer den Inhalt des zuletzt gecachten Files.

Danke!
Ich merke gerade, das zu viel guten Wein aus Schwiegervaterns Keller nicht unbedingt fördernd wirkt :}

Schöner wäre, wenn die Argumente für die Cache-Items direkt im Konstruktor übergeben werden... (also RequestCache *r = new RequestCache(f, d); ).

Ich hab das mal aufgegriffen und umgebaut & schon läuft es wie geschnitten Brot!

Code:

siege -v -b -t30s -c5 http://localhost:8080/index.html

Lifting the server siege..      done.
Transactions:                  37332 hits
Availability:                 100.00 %
Elapsed time:                  29.11 secs
Data transferred:               2.60 MB
Response time:                  0.00 secs
Transaction rate:            1282.45 trans/sec
Throughput:                     0.09 MB/sec
Concurrency:                    4.88
Successful transactions:       37332
Failed transactions:               0
Longest transaction:            0.12
Shortest transaction:           0.00

Flink. Naja, bei einer einzigen statischen Seite, die nix wirklich kann ...

**TheDodger** · 14-01-2011, 10:36

Ich hab da eine Theorie, wieso das mit dem POST nicht so klappt ...
Liegt das evtl. daran, dass der Request in einem Thread abgearbeitet wird und der irgendwie Probleme mit dem syncronisieren der IP / Ports bekommt?

Denn anders kann ich mir das jetzt nicht mehr erklären.
Ich hab das jetzt auch erstmal weiter nach hinten verschoben um mit Cookie & Session weiterzumachen ...

**TheDodger** · 18-01-2011, 09:41

Zitat von TheDodger

Ich hab da eine Theorie, wieso das mit dem POST nicht so klappt ...
Liegt das evtl. daran, dass der Request in einem Thread abgearbeitet wird und der irgendwie Probleme mit dem syncronisieren der IP / Ports bekommt?

Ich habe mal unterschiedliche Wege ausprobiert, um an die Daten zu kommen:
#1

Code:

   bool done = true;
   
   do {

      usleep(500);

      pRawHeaderData.append( socket->readAll() );
      
      done = socket->atEnd();
      socket->flush();      
   } while( !done );

#2

Code:

   while( socket->waitForDisconnected( 100 ) ) {
      
      pRawHeaderData.append( socket->readLine() );
   }

#3

Code:

   while( socket->canReadLine() ) {

      pRawHeaderData.append( socket->readLine() );
   }

Nur um zu sehen, ob sich da irgendwas ändert.

Aber was soll ich sagen?
Das Ergebniss bleibt immer das gleiche ...

**anda_skoa** · 18-01-2011, 12:00

Vielleicht eher so:

Code:

do {
  while ( socket->waitForReadyRead( 100 ) ){
    pRawHeaderData.append( socket->read( socket->bytesAvailable() ) );
  }
} while (!socket->atEnd())

Ciao,
_

**TheDodger** · 18-01-2011, 13:23

Zitat von anda_skoa

Vielleicht eher so:

Code:

do {
  while ( socket->waitForReadyRead( 100 ) ){
    pRawHeaderData.append( socket->read( socket->bytesAvailable() ) );
  }
} while (!socket->atEnd())

Test ich nachher mal genauer.
Beim reinen c'n'p ist das eine Endlosschleife

[edit]
Nein, es aendert sich nicht.
Ich hab auch gerade keine Moeglichkeit gefunden aus der do while schleife auszubrechen ...

**TheDodger** · 20-01-2011, 09:19

Zitat von TheDodger

Test ich nachher mal genauer.
Beim reinen c'n'p ist das eine Endlosschleife

[edit]
Nein, es aendert sich nicht.
Ich hab auch gerade keine Moeglichkeit gefunden aus der do while schleife auszubrechen ...

Ich nehme alles zurück, was ich vorher behauptet habe!
Ich hab das ganze mal mit 'make clean' gesäubert und neu gebaut und siehe da ... jetzt gehts auch!
Was freu ich mich

Danke!

**TheDodger** · 29-01-2011, 14:09

Moin Moin!

Ich habe jetzt eine halbwegs lauffähige Version (download).

Momentan speichere ich die Sessions in einer sqlite-DB, bin mir aber nicht sicher, ob das als eine Performancebremse auswirken könnte.

PHP hat ja nicht wirklich was mit typsicheren Variablen am Hut, so dass man dort (in den Sessions) problemlos ganze Arrays reindrücken kann. Wenn ich diese Funktionalität noch implementieren will, wüsste ich noch gar nicht wie.
Mal abgesehen davon halte ich sie nicht gerade für sinnvoll.

So, schaut euch das Ding an wenn ihr wollt.
Über Kritik und Anregungen bin ich echt dankbar, also übt keine Zurückhaltung!

**TheDodger** · 30-01-2011, 13:19

Nachdem ich nun soweit bin, habe ich wohl noch ein einzigest Problem ... und zwar das Ding mit den Plugins.

Mein Wunschverhalten wäre dieses:
Beim Start des Servers werden die Verfügbaren Plugins geladen und können dann generell von überall her genutzt werden.

Aktuell scheine ich da aber an eine meiner (momentanen) Grenzen gestossen zu sein.
Wenn ich die Plugins in der Klasse RIPCoreApplication lese, kann ich diese in Request nicht benutzen, also muß ich die da wieder laden.

Und ich möchte nicht wirklich, dass die Plugins bei jedem Request neu geladen werden müssen. Dann brauch ich auch gar keine ...

Gibt es da für mich keine Elegantere Lösung?
Anda Skoa? Vielleicht hast du eine Idee?

Thema: (HTTP) Server mit Qt4

Themen-Optionen

Thema bewerten

Anzeige

Hybrid-Darstellung

Stichworte

Lesezeichen

Lesezeichen

Berechtigungen