SSL-Server mit select()?

[RoRoe]

Hy
Weiß irgend jemand, wie ich einen Server aufbaue der SSL_write() und SSL_read() nutzt und dazu noch mit select() verschiedene Client gleichzeitig bedient?
Wenn jemand ne Idee, Lösung oder auch nur nen Ansatz hat, dann bitte melden!
Danke RoRoe

[jgbauman]

Mal so geraten:
Mit

int SSL_get_fd(SSL *ssl);
int SSL_get_rfd(SSL *ssl);
int SSL_get_wfd(SSL *ssl);
erhaelt man den file descriptor zu einer SSL-Connetion (falls einer existiert).
Dieser file descriptor sollte eigentlich ganz einfach mit select arbeiten koennen.

[RoRoe]

Schön gedacht, aber leider falsch!
a) Brauche ich das "SSL *ssl" für die Funktion SSL_read(SSL *ssl,...)
b) Eine SSL- Verbindung ist aufgrund der Zertifikate ein Unikat und somit nicht einfach ersetzbar durch einen beliebigen Socket

Trotzdem Danke für den Tip!
Vielleicht hat ja noch jemand eine Idee!

[micha]

Hallole,

Es gibt n Buch "SSL and TLS" (englisch), in dem u.a. das Programmieren mit OpenSSL beschrieben wird. Den Quellcode der Beispiele im Buch gibts auch hier: http://www.rtfm.com/sslbook/

Vielleicht hilft das ein wenig weiter ;)

P.S: Mit select() kannst Du nur bedingt arbeiten, d.h genau einmal, und zwar wenn z.B. etwas zum Lesen ansteht, sagen wir 1024 bytes. Benutzt Du dann SSL_read() mit einem Puffer von 100 Bytes pro Schleife, holt SSL_read() trotzdem die ganzen 1024 Bytes aus dem Netzwerk-Puffer, da SSL sonst die MAC nicht überprüfen kann. D.h., wenn Du jetzt ein zweites Mal mit select() schaust, ob noch was im Netzwerk-Puffer ist, kommt als Antwort leer, obwohl die restlichen 924 Bytes noch im SSL-Puffer stecken. Dafür brauchst Du dann die SSL_pending()-Funktion. Die Implementation ist in den Quellcodes...
(ich hoffe es einigermaßen verständlich erklärt zu haben ;) )

Gruß micha

[ 17. Juni 2001: Beitrag editiert von: micha ]

[RoRoe]

Also, erstmal vielen Dank!
Aber da ich immer noch nicht weiterkomme werde ich halt das Problem etwas näher erläutern!
Zuerst war da eine programmierte Chatsoftware zum aufsetzen eine einfachen Chatservers( enthielt Serversoftware & Clientsoftware ) wobei der Server dafür sorgte das die Nachricht eines Clients automatisch an alle anderen Clients gesendet wurde. Das realisierte ich mit select(), da ich für die fork()-Variante keine Lösung sah!
Der Server schickt also die Nachricht an alle in registrierten Connections. Mit SSL ist das nicht mehr so einfach, da jede Connection eine eignes Zertifikat besitzt und man nicht mehr mit:
"for(check=fdmin;check=fdmax;check++)
{
FD_ISSET(....);
SSL_write(ssl,.....);
}
die Client bedienen kann. Auch wenn man vor SSL_write(..) noch ein SSL_clear(ssl) und danach ein SSL_set_fd(ssl,client) gibts nen Error!
Ich hoffe ich hab mich halbwegs klar artikuliert und ihr könnt mir helfen!
Danke und Tschau!

[jgbauman]

Vielleicht wuerde es sich lohnen von fork auf Threads umzusteigen. Dann ist die Kommunikation zwischen den Aktivitaetstraegern billiger (passende Locks um die Datenstrukturen z.B. Warteschlangen, aber nicht unbedingt kopieren notwendig). Nachteil: Maximale Anzahl der Clients von maximaler Threadzahl abhaengig. Da sich die Threads wahrscheinlich am Kernel blockieren koennen sollen wenn sie auf Input warten waere 1:1 oder M:N sinnvoll.
M:N unter linux ist aber noch beta http://oss.software.ibm.com/developerworks/opensource/pthreads/ . Bei 1:1 ist unter Linux die maximale Threadanzahl die maximale Prozessanzahl. Das koennte natuerlch zu Problemen fuehren.

Vielleicht waere eine Implementierung mit 4 1:1-Threads sinnvoll:
1. Thread: wartet nur auf neue Connections und fuegt sie ins System ein.
2. Thread: Liest nur den input von allen clients. Beruecksichigung der doppelten Bufferung select/SSL_pending ist Aufwand, aber da es alles ist, worum sich dieser Thread kuemmern muss sollte es nicht allzuschwierig sein. Gelesen Daten landen in Warteschlange A.
3. Thread: Kuemmert sich um die Verteilung der Daten aus Warteschlange A. Haengt zu verschickende Packete in Warteschlange B.
4. Thread: Versendet alle Daten aus der Warteschlange B. Vielleicht verteilt er die Packete vorher auch in Warteschlangen pro Client. (Kann das Chat-Protokoll auch mehrere Messages in einem Packet verschicken?)

Bei entsprechend intelligenten Synchronisationsmassnahmen an den Warteschlangen sollte die Performance kein Problem sein. (Entfernen vom Anfang moeglich, auch wenn am Ende hinzugefuegt wird, solange genug Elemente dazwischen sind). Wahrscheinlich ist aber sowieso der I/O-Durchsatz die Engstelle.

Je nachdem wie portabel das ganze sein soll ist poll() als Ersatz fuer select() interessant.

[ 18. Juni 2001: Beitrag editiert von: jgbauman ]