These are chat archives for paypal/squbs
firstSessionseems to consume the
enabledCipherSuites. Perhaps I'm missing something. Even in TLS, I cannot find access to
AkkaSSLConfig.configureCipherSuitesPerhaps I have not reviewed their code enough.
AkkaSSLConfigcipher suites get populated into
SSLEnginevia line 84, through its
ConnectionContext.httpsgets populated into
firstSessionwhich then is used to construct
finalSessionParameters. This is applied to the
SSLEnginevia line 99.
SSLEngine.setEnabledProtocols. In the first case, it is mandatory and it comes from
SSLContext.getDefaultSSLParameters. In the second place (line 99) that line internally calls
SSLEngine.setEnabledProtocolsin case the
ConnectionContext.https, if not
None, overrides the defaults in
enabledCipherSuitesfrom a selection between the
SSLConfigSettings, and in case there the latter is
Ciphers.recommendedCiphers. Basically, the ciphers must be in
SSLContext.getDefaultSSLParametersin order to be in the list. This ensures only valid cipher suites are selected.
SSLConfigSettingspassed to the
None, select only the suites available from
None, select suites from
Ciphers.recommendedCiphersand take only the ones available from
firstSessionand, if not
None, apply those by calling
SSLEngine.setEnabledCipherSuites, thus overriding anything from
ConnectionContext.httpsparameters, if set, takes precedence. Then the massaged ones in
AkkaSSLConfig, if set. Finally use massaged ones from
Ciphers.recommendedCiphers. The two latter only if the suite also exists in
application.conf, one overriding each others, that can be used.
SSLParametersas a parameter as well.. It could define cipherSuites as well.. If so, that would take the most precedence..
SSLContextis passed to
SSLEngineis created from this.. But, a new
SSLContextobject is create in https://github.com/akka/akka/blob/v2.4.14/akka-stream/src/main/scala/com/typesafe/sslconfig/akka/AkkaSSLConfig.scala#L72..
sslParameterswill even override the
enabledProtocolsas you can see at https://github.com/akka/akka/blob/v2.4.14/akka-stream/src/main/scala/akka/stream/impl/io/TLSActor.scala#L469
BidiFlow? It is one in - one out. Out would either be actual result or timeout result.. What would the two ports be connected to ?
BidiFlow, if could very well be a pipeline handler.
TimeoutStage[T, U]would be a
BidiFlow[T, T, Try[U], Try[U]]
def withTimeout[In, Out, Mat](flow: Flow[In, Out, Mat]): Flow[In, Try[Out], Mat]
Flowthat gets encapsulated into another
Flow. Just thinking about the model, that would essentially constitute a
BidiFlow. It also makes me think back to our commit stages with
PersistentBufferand whether that would constitute a
BidiFlow. The story would get much messier with
BroadcastBuffer, though. So I think we can leave it alone for the time being.
~> | TimeoutStage | ~> | Some Processing | <~ | | <~ | |
delaystage would be backpressuring..
mapAsyncand a scheduler, this buffer size would be the
Flowyou'll be dealing with far less waiting requests. We need to decide whether to supply it with a configuration or pass this in the API.