You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by radai <ra...@gmail.com> on 2016/11/02 23:24:20 UTC
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?
Re: why cant SslTransportLayer be muted before handshake completion?
Posted by radai <ra...@gmail.com>.
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 Chintalapani <ka...@harsha.io> wrote:
> 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 <jj...@gmail.com> 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 <ra...@gmail.com>
> 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?
Posted by Harsha Chintalapani <ka...@harsha.io>.
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 <jj...@gmail.com> 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 <ra...@gmail.com> 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?
Posted by Joel Koshy <jj...@gmail.com>.
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 <ra...@gmail.com> 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?
>