Re: why cant SslTransportLayer be muted before handshake completion?
the root issue is i may not have enough available memory to read from the socket. I'll do the simple thing and just avoid muting handshaking sockets, for now. On Wed, Nov 2, 2016 at 6:59 PM, Harsha Chintalapaniwrote: > HI Radai, > One main reason is to keep the handshake details away from > the application layer. i.e Kafka network layer which is sending Kafka > protocols doesn't need to worry about the handshake details, all it needs > is a validation that the connection is completed and it can start sending > Kafka protocols over the wire. So when a client tries to connect to a > broker's SSL port, it goes through the handshake, if we mute the channel, > Kafka network need to decide when to unmute it that means leaking some of > the SSL connection details in Kafka Selector code. Given that we are > supporting multiple Secure channels and each has its handshake mechanism we > kept the selector code the same irrespective of which channel/port/security > its trying to use. The details will be handled by the TransportLayer its > job is to finish the handshake and return the ready() to be true when its > ok for the client to start sending requests. > As Joel said, it's possible to pause/resume the handshake but > not sure why its needed; you can treat that as a black box and start > sending your requests once the channel.ready(). I haven't gone through > KIP-72 proposal so I might be missing something here. > > Thanks, > Harsha > > On Wed, Nov 2, 2016 at 5:01 PM Joel Koshy wrote: > > > Sriharsha can validate this, but I think the reason is that if we allow > > muting/unmuting at will (via those public APIs) that can completely mess > up > > the handshake itself. It should be possible to pause/resume the handshake > > if that's what you'r elooking for but I'm not sure it is worth it for the > > purposes of KIP-72 given the small volumes of reads/writes involved in > > handshaking. > > > > On Wed, Nov 2, 2016 at 4:24 PM, radai > wrote: > > > > > Hi, > > > > > > as part of testing my code for KIP-72 (broker memory control), i ran > into > > > the following code snippet in SslTransportLayer: > > > > > > public void removeInterestOps(int ops) { > > > if (!key.isValid()) > > > throw new CancelledKeyException(); > > > else if (!handshakeComplete) > > > throw new IllegalStateException("handshake is not > > completed"); > > > > > > key.interestOps(key.interestOps() & ~ops); > > > } > > > > > > why cant an ssl socket be muted before handshake is complete? > > > > > >
Re: why cant SslTransportLayer be muted before handshake completion?
HI Radai, One main reason is to keep the handshake details away from the application layer. i.e Kafka network layer which is sending Kafka protocols doesn't need to worry about the handshake details, all it needs is a validation that the connection is completed and it can start sending Kafka protocols over the wire. So when a client tries to connect to a broker's SSL port, it goes through the handshake, if we mute the channel, Kafka network need to decide when to unmute it that means leaking some of the SSL connection details in Kafka Selector code. Given that we are supporting multiple Secure channels and each has its handshake mechanism we kept the selector code the same irrespective of which channel/port/security its trying to use. The details will be handled by the TransportLayer its job is to finish the handshake and return the ready() to be true when its ok for the client to start sending requests. As Joel said, it's possible to pause/resume the handshake but not sure why its needed; you can treat that as a black box and start sending your requests once the channel.ready(). I haven't gone through KIP-72 proposal so I might be missing something here. Thanks, Harsha On Wed, Nov 2, 2016 at 5:01 PM Joel Koshywrote: > Sriharsha can validate this, but I think the reason is that if we allow > muting/unmuting at will (via those public APIs) that can completely mess up > the handshake itself. It should be possible to pause/resume the handshake > if that's what you'r elooking for but I'm not sure it is worth it for the > purposes of KIP-72 given the small volumes of reads/writes involved in > handshaking. > > On Wed, Nov 2, 2016 at 4:24 PM, radai wrote: > > > Hi, > > > > as part of testing my code for KIP-72 (broker memory control), i ran into > > the following code snippet in SslTransportLayer: > > > > public void removeInterestOps(int ops) { > > if (!key.isValid()) > > throw new CancelledKeyException(); > > else if (!handshakeComplete) > > throw new IllegalStateException("handshake is not > completed"); > > > > key.interestOps(key.interestOps() & ~ops); > > } > > > > why cant an ssl socket be muted before handshake is complete? > > >
Re: why cant SslTransportLayer be muted before handshake completion?
Sriharsha can validate this, but I think the reason is that if we allow muting/unmuting at will (via those public APIs) that can completely mess up the handshake itself. It should be possible to pause/resume the handshake if that's what you'r elooking for but I'm not sure it is worth it for the purposes of KIP-72 given the small volumes of reads/writes involved in handshaking. On Wed, Nov 2, 2016 at 4:24 PM, radaiwrote: > Hi, > > as part of testing my code for KIP-72 (broker memory control), i ran into > the following code snippet in SslTransportLayer: > > public void removeInterestOps(int ops) { > if (!key.isValid()) > throw new CancelledKeyException(); > else if (!handshakeComplete) > throw new IllegalStateException("handshake is not completed"); > > key.interestOps(key.interestOps() & ~ops); > } > > why cant an ssl socket be muted before handshake is complete? >
why cant SslTransportLayer be muted before handshake completion?
Hi, as part of testing my code for KIP-72 (broker memory control), i ran into the following code snippet in SslTransportLayer: public void removeInterestOps(int ops) { if (!key.isValid()) throw new CancelledKeyException(); else if (!handshakeComplete) throw new IllegalStateException("handshake is not completed"); key.interestOps(key.interestOps() & ~ops); } why cant an ssl socket be muted before handshake is complete?