Java SSL (mit ehrlicher Frage) (was: Re: [linux-l] Re: funny university names)

Steffen Dettmer steffen at dett.de
Sa Feb 3 12:55:50 CET 2007


* Nico Golde wrote on Thu, Feb 01, 2007 at 18:51 +0100:
> > > > Am Mi, Jan 31, 2007 10:50:24 +0100, Steffen Dettmer schrieb:
> > > > > Frage zu Java (javax.net.ssl): Wie benutzt man diese (oder meintwegen
> > > > > auch eine andere) SSL Lib, um auf etwas abstrakterem als TCP SSL zu
> > > > > fahren?
> > > > 
> 
> http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/package-summary.html
> Gelesen nicht, ich werde mich hüten mehr, als die Java-Doku
> die ich lesen muss, zu lesen ;)

Diese Dokumentation kenne ich, aber die hat mir nicht geholfen. Zwar
stellt die Doku korrekt fest, dass

  "Such sockets are normal stream sockets, but they add a layer of
   security protections over the underlying network transport protocol,
   such as TCP."

allerdings scheint die Implementierung auf TCP beschränkt zu sein. Sowas
ist man ja leider von Java gewöhnt. Leider sind auch die Sourcen der
SSL-Klassen nicht in src.zip drin, so dass man nichtmal gucken kann, ob
man das notfalls mit viel Fleissarbeit "zurechtableiten" könnte. So
einfach geht das jedenfalls nicht (glaube ich), weil SSLSocket
sicherlich geerbte super.methoden() aufruft, das heisst, wenn methode()
überschrieben ist, sieht das SSLSocket überhaupt nicht, weil
super.methode() ja das gleiche bleibt.

SSLSocket ist meiner Meinung nach ein klarer Designfehler. Korrekt wäre
ein Aggregat, ein Decorator oder vergleichbar. Das ist meiner Meinung
nach recht klar, da man ja schon sagt "SSL setzt auf (z.b.) TCP auf" und
nicht "SSL *ist* ein TCP mit folgenden Eigenschaften...". Also kein "ist
ein", sondern "benutzt ein" oder "hat ein". Also ein Aggregat. Bei

Sockets ist das ja ähnlich. Sinngemäss können die alles... was TCP ist.
Da ist POSIX objektorientierter (weil filedescriptoren z.B. immer ein
read und write haben, was das Richtige macht - egal ob Datei, TCP oder
RS232, soviel abstraktion hab ich bisher noch nirgendwo sonst gesehen).
Und das ist älter, da darf man auch mal gute Konzepte übernehmen...

Statt "SSLSocket(InetAddress address, int port)" müsste es 
"SslSocket(Socket underlying)" sein. Obwohl Socket eh blöd wäre, wo Java
doch behauptet, diese bekloppten must-poll "InputStreams" wäre das Grüne
vom schimmligen Ei, also müsste es sogar
SslSocket(InputStream in, OutputStream out)
heissen. Da könnte man dann natürlich kein select mehr benutzen. Obwohl
das nio-selectable-Zeug ja anscheinend auch wieder nur funktioniert,
wenn man nur einen Thread auf dem Socket arbeiten lässt[1]. Andere
Threads sollen dann über Message-Queues an diesen Thread schicken, was
zu schreiben ist bzw. gelesene Daten zurückbekommen! Es ist unglaublich,
aber wurde mir so von mehreren Seiten erklärt! Na ja, was bei Java alles
unglaublich ist, würde Bücher füllen...

Wobei ich mich bei solchen Sachen frage, wie sowas passiert. Haben die
Lebensmitteltechnik-Studenten, die die Java-APIs machen, nie ein
Unixbuch gelesen? SCNR.

oki,

Steffen

[1] Beispiel-URL: http://rox-xmlrpc.sourceforge.net/niotut/index.html

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.





Mehr Informationen über die Mailingliste linux-l