Le 5/3/12 12:11 PM, Emmanuel Lécharny a écrit :
Le 5/2/12 8:00 PM, Julien Vermillard a écrit :
+1
Ok, I have committed some changes, but I'm still not pleased with what
we get at the end.
The problem is that in order to get a TCP session secured, we have to
store the SSLContext somwhere. If we stores it into the
AbstractTcpServer/Client, then we stores it in two different places.
The very same for the initialization : we have to implement the init
code in two classes...
If we want to have this filed and method shared, we should have them
in the AbstractIoService, but then, it will be visible for the UDP
classes...
Another solution would be to get rid of this SSLContext field, and to
move it into the IoSessionConfig TCP implementation...
I do think, atm, that it would be a better solution.
thoughts ?
Btw, the IoSessionConfig hierarchy is a bit limited, we may want to
improve it by creating a TcpSessionConfig and an UdpSession config
instead of the DefaultSocketSessionConfig...
Some more thougts : securing the session has nothing to do with the
service itself. At this point, having a method like
IoService.isSecured() makes no sense.
I think I added this method whith things like HTTPS or LDAPS in mind,
and it was a bad move. It does not reflect what's going on : first the
SSL layer works on a session, second with StartTLS, you can perfectly
well switch from a non secured to a secured session, live.
I'll remove the isSecured() and setSecured() methods from the IoService.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
