ssl - Java TLS Session Reuse after closed connection -


i have java tls client can send series of requests server, each followed response server.

however, there many different servers. "multi-message" servers keep connection open after first request, subsequent requests can sent on first connection. others "single-message" servers close connection after each message , new connection required subsequent messages. there no priori way client know type of server talking to, nor fix servers.

it desirable single-message serves able resume session without full handshake.

my original client code tried send subsequent requests down same connection. if failed opened new connection server. handle both single , multi-message servers.

however, failure when sending second message single-message severs seems kill session resumption.

my dirty work around notice if message fails , assume talking single-message server, in case client explicitly closes socket after each response has been received. enables subsequent connections resume sessions.

but there has better way. testing isinputshutdown or isconnected not help, unsurprisingly, there timing issues. connection failure single-message server happens during read of response, after write of request, presumably due buffering.

any ideas appreciated?

your initial solution correct in case of plaintext: ioexception: connection reset peer when sending second message, , can recover accordingly reconnecting.

however in tls case won't work, not ioexception: connection reset peer socketexception, due fatal tls unexpected_message alert. rfc 2246 #7.2 states:

alert messages level of fatal result in immediate termination of connection. in case, other connections corresponding session may continue, the session identifier must invalidated, preventing failed session being used establish new connections.

[my emphasis], because failed session deemed insecure, and

unexpected_message

an inappropriate message received. alert fatal , should never observed in communication between proper implementations.

your second solution seems appropriate me.

nb:

  • isinputshutdown() can never true, can't call shutdowninput() on sslsocket.
  • isconnected() never false once socket has been connected.
  • both tell state of socket, not of connection, trying them futile. , has nothing 'timing issues'.

Comments

Popular posts from this blog

scala - 'wrong top statement declaration' when using slick in IntelliJ -

c# - DevExpress.Wpf.Grid.InfiniteGridSizeException was unhandled -

PySide and Qt Properties: Connecting signals from Python to QML -