Re: [akka-user] AKKA crashed using kryo serialization sometimes

[Любен]

No, it's all done in the akka serializer thread. I am sure also for LZ4Java
that it does not use any parallelism itself.

On Tue, Mar 7, 2017 at 5:48 AM, Patrik Nordwall <patrik.nordw...@gmail.com>
wrote:

> Is Kryo (or the library) delegating to a different thread somehow?
>
> mån 6 mars 2017 kl. 22:13 skrev Любен <karave...@gmail.com>:
>
>> Hi,
>>
>> It's strange, I have put the LZ4 compression in the kryo serialization
>> extension. Actually I am relying on it in production (compiled from the
>> same source). The only difference I see is that it's using the artery
>> transport. Could it be that the source byte buffer is released earlier by
>> artery, when it is still in the serializer and the byte array get
>> corrupted? I think it may show only when using more time-consuming
>> serialization.
>>
>> Regards,
>> luben
>>
>> On Mon, Mar 6, 2017 at 8:21 AM, Konrad Malawski <
>> konrad.malaw...@lightbend.com> wrote:
>>
>>
>> Really? I was thing serialization would be needed for inter process
>> communication.
>>
>> If you're in the same JVM then it's only inter-thread communication, so
>> we don't serialize (unless you force that via config setting)
>>
>>
>> Thanks, looking forward to a reproducer - most likely best to ping the
>> kryo plugin people, thanks!
>>
>>
>> -- Konrad
>>
>>
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/
>> current/additional/faq.html
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/
>> current/additional/faq.html
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/
> current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] AKKA crashed using kryo serialization sometimes

[Любен]

Hi,

It's strange, I have put the LZ4 compression in the kryo serialization
extension. Actually I am relying on it in production (compiled from the
same source). The only difference I see is that it's using the artery
transport. Could it be that the source byte buffer is released earlier by
artery, when it is still in the serializer and the byte array get
corrupted? I think it may show only when using more time-consuming
serialization.

Regards,
luben

On Mon, Mar 6, 2017 at 8:21 AM, Konrad Malawski <
konrad.malaw...@lightbend.com> wrote:

>
> Really? I was thing serialization would be needed for inter process
> communication.
>
> If you're in the same JVM then it's only inter-thread communication, so we
> don't serialize (unless you force that via config setting)
>
>
> Thanks, looking forward to a reproducer - most likely best to ping the
> kryo plugin people, thanks!
>
>
> -- Konrad
>
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/
> current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Akka Java IO TLS

[Любен]

I have found handing SSL/TLS from JVM a PITA. Why you don't put the SSL
termination in front of the Akka HTTP endpoint (e.g. nginx) ?

On Wed, Jul 27, 2016 at 4:36 PM, Akka Team  wrote:

> The easiest path would probably be Akka Streams for TCP (
> http://doc.akka.io/docs/akka/2.4/scala/stream/stream-io.html) and the
> existing TLS graph module (http://doc.akka.io/api/akka/
> 2.4/#akka.stream.scaladsl.TLS$). There isn't much documentation on the
> TLS module, but you should be able look at how it is used in Akka HTTP.
>
> I don't think you would benefit hugely from the fact that Akka remoting
> uses Netty if you want to go down that path, most of the classes are Akka
> private and not very generic. You can of course just introduce Netty as a
> separate dependency and use that directly if you want.
>
> --
> Johan
>
> On Thu, Jul 21, 2016 at 9:12 PM, Vinay Gajjala  wrote:
>
>> After rethinking and researching was wondering if I can configure/code
>> the netty API which Akka uses to achieve the TLS. I am now sure how
>> efficient is this. Any help would be greatly appreciated
>>
>> Thanks
>> Vinay
>>
>> On Monday, July 18, 2016 at 11:13:33 AM UTC-5, Vinay Gajjala wrote:
>>>
>>> Hi
>>>
>>> I am a newbie in Akka and I implemented a TCP server which listens to
>>> device traffic. I have searched online and could not find any concrete
>>> examples of how to configure TLS using Akka IO.
>>>
>>> I am not sure if I am missing the obvious.
>>>
>>> Thanks in advance,
>>> Vinay
>>>
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: http://doc.akka.io/docs/akka/
>> current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/
> current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] com.github.romix.akka:akka-kryo-serialization_2.11 and AES Transform?

[Любен]

The security of the AES encryption depends on using non-repeating IVs
(nounces) and it will result in different cyphertext.

Regards,
luben

On Thu, May 26, 2016 at 7:31 AM, kraythe  wrote:

> I have Been integrating this extension (which is mentioned in the Akka
> docs and is great) and I am having a problem. Basically it seems that when
> I enable the AES transform it generates a different serialized bytes each
> time which causes problems with hazelcast that uses the byte
> representations for equals. Is there a way I can encrypt the entities and
> still allow for the generated encryption to be stable? Here is my config (i
> have altered my encryption key for this post)
>
> kryo {
>   type = "graph"
>   idstrategy = "automatic"
>   buffer-size = 4096
>   max-buffer-size = -1
>   use-manifests = false
>   post-serialization-transformations = "lz4,aes"
>   kryo-custom-serializer-init =
> "distributed.serialization.SerializationConfigUtil"
>   encryption {
> aes {
>   mode = "AES/CBC/PKCS5Padding"
>   # TODO configure per-environment key
>   key = 6XdyUTgEDicqL6R9
>   IV-length = 16
> }
>   }
>   implicit-registration-logging = true
>   kryo-trace = false
> }
>
> Thanks in advance.
>
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Custom Serialization with FST or Kryo ?

[Любен]

Have you tried Akka-Kryo-Serializatio[1] ? It should work out of the box
with "default" or "automatic" id-strategy. And it has other optional parts
that may come handy, e.g. transparent compression using LZ4 or AES
encryption.

Regards,
luben


[1] https://github.com/romix/akka-kryo-serialization

On Tue, May 24, 2016 at 11:58 PM, kraythe  wrote:

> Has anyone used FST Serialization[1] with their Akka messages? If so, how
> did it work out? I am debating using this or Kryo for serialization and FST
> seems to be faster and more "drop-in" compliant so i was curious if anyone
> had tried it. If you have tried Kryo before I would be interested in your
> experience. Id like to stay away from Java serialization and protobuf is a
> non-starter as I have tons of code I am moving to akka that I can't just
> re-engineer.
>
> Thanks.
>
> -- Robert
>
> [1] https://github.com/RuedigerMoeller/fast-serialization
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Remoting transport back-pressure

[Любен]

Hi Guido,

Thanks for the pointer to the chopping head mailbox. I will take a look,
sounds really interesting. I am already using different bounded mailboxes
between the Source and the Processing actor depending on the semanitcs of
the computation: if the source is shared between multiple processing actors
(in the cases where getting the results on-time is more important than
processing all the data) I use non-blocking mailbox. If the source is not
shared and I care about processing all the input data I use blocking
mailbox to slow-down the source.

Regards,
luben

On Tue, Feb 16, 2016 at 10:13 AM, Guido Medina  wrote:

> Hi Luben,
>
> There are other types of mailboxes good for that (depending on your
> requirements) you have bounded non-blocking and I'm not 100% sure but I
> think I read somewhere that in Akka streams you have a bounded chopping
> head sink, say you don't care about head messages that have taken too long
> to process and only the last newest 10k, etc.
>
> HTH,
>
> Guido.
>
> On Monday, February 15, 2016 at 6:47:33 PM UTC, Luben Karavelov wrote:
>>
>> Hi Michael,
>>
>> I have taken another approach. I already had a Send/Ack flow control over
>> the network. So I extended it to use the 'ask' and wait for the Ack from
>> the collecting actor in order to exersice back-pressure to the source.
>> Using blocking and bounded queue will also block the source after the queue
>> is full.
>>
>> Thanks for the advice,
>> luben
>>
>> On Fri, Feb 12, 2016 at 6:59 PM, Michael Frank 
>> wrote:
>>
>>> i think you will need to implement your own acking protocol.
>>>
>>> SourceActor sends something like PushMessage to ProcessingActor, which
>>> enriches the message with some processing, then sends to the remote
>>> CollectingActor.  CollectingActor then responds to ProcessingActor with
>>> AckMessage.  ProcessingActor forwards the AckMessage to SourceActor.  Once
>>> SourceActor receives AckMessage it sends the next PushMessage.
>>>
>>> I don't think bounded mailboxes are a good solution, because they have a
>>> fixed capacity, and that capacity is not related to your network capacity.
>>> an acking protocol will get you better network utilization, and be more
>>> tolerant/performant with respect to changing network conditions.
>>>
>>> -Michael
>>>
>>> On 02/10/16 17:37, Luben Karavelov wrote:
>>>
>>> Hi,
>>>
>>> I have the following push dataflow using remote actors (netty.tcp
>>> transport) over the network:
>>>
>>> SourceActor -> ProcessingActor ~~ network ~~>  CollectingActor
>>>
>>> The problem is that if the network is relatively slow the processing
>>> actor successfully sends the messages but they get all buffered inside the
>>> same JVM until it blows with OOM. I am looking how to slow down the
>>> SourceActor if the upstream network is slower than the production rate. I
>>> have put bounded mailbox between the Source and Processing actor but it
>>> does not help because the ProcessingActor is not slowed by the network
>>> transport.
>>>
>>> I looked at the code and it looks the problem arises because the
>>> EndpointWriter actor (that is kind of a proxy between the local actors and
>>> the transport as far as I understand) buffers the data to be sent in itself.
>>>
>>> So here are my questions:
>>>
>>> 1. Is there a way to create a back-pressure between the network
>>> transport and the sender?
>>>
>>> 2. If there is no way and I have to create an application level
>>> flow-control over the network (between the Processing and Collecting
>>> actors) what will be the best way to slow down the SourceActor? Should I
>>> extend the flow control down to it? Or is there a way to slow down the
>>> reception of messages coming from the SourceActor so that the bounded
>>> mailbox will slow it down (I will still need the other messages to be
>>> delivered for flow-control signalization)?
>>>
>>> Thanks in advance for any advises and suggestions,
>>> luben
>>>
>>>
>>>
>>> --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ:
>>> 
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives:
>>> 
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to akka-user+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>> --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ:
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives:
>>> 

Re: [akka-user] Remoting transport back-pressure

[Любен]

Hi Michael,

I have taken another approach. I already had a Send/Ack flow control over
the network. So I extended it to use the 'ask' and wait for the Ack from
the collecting actor in order to exersice back-pressure to the source.
Using blocking and bounded queue will also block the source after the queue
is full.

Thanks for the advice,
luben

On Fri, Feb 12, 2016 at 6:59 PM, Michael Frank 
wrote:

> i think you will need to implement your own acking protocol.
>
> SourceActor sends something like PushMessage to ProcessingActor, which
> enriches the message with some processing, then sends to the remote
> CollectingActor.  CollectingActor then responds to ProcessingActor with
> AckMessage.  ProcessingActor forwards the AckMessage to SourceActor.  Once
> SourceActor receives AckMessage it sends the next PushMessage.
>
> I don't think bounded mailboxes are a good solution, because they have a
> fixed capacity, and that capacity is not related to your network capacity.
> an acking protocol will get you better network utilization, and be more
> tolerant/performant with respect to changing network conditions.
>
> -Michael
>
> On 02/10/16 17:37, Luben Karavelov wrote:
>
> Hi,
>
> I have the following push dataflow using remote actors (netty.tcp
> transport) over the network:
>
> SourceActor -> ProcessingActor ~~ network ~~>  CollectingActor
>
> The problem is that if the network is relatively slow the processing actor
> successfully sends the messages but they get all buffered inside the same
> JVM until it blows with OOM. I am looking how to slow down the SourceActor
> if the upstream network is slower than the production rate. I have put
> bounded mailbox between the Source and Processing actor but it does not
> help because the ProcessingActor is not slowed by the network transport.
>
> I looked at the code and it looks the problem arises because the
> EndpointWriter actor (that is kind of a proxy between the local actors and
> the transport as far as I understand) buffers the data to be sent in itself.
>
> So here are my questions:
>
> 1. Is there a way to create a back-pressure between the network transport
> and the sender?
>
> 2. If there is no way and I have to create an application level
> flow-control over the network (between the Processing and Collecting
> actors) what will be the best way to slow down the SourceActor? Should I
> extend the flow control down to it? Or is there a way to slow down the
> reception of messages coming from the SourceActor so that the bounded
> mailbox will slow it down (I will still need the other messages to be
> delivered for flow-control signalization)?
>
> Thanks in advance for any advises and suggestions,
> luben
>
>
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> 
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives:
> 
> https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Akka User List" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/akka-user/UYojosSS298/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Akka-Http with ActorPublisher source

[Любен Каравелов]

Hi,

I have built a small HTTP EventSource endpoint prototype based on 
akka-streams-1.0-M3 for a system that I am working on. It turned quite 
well. I have tried to upgrade it to 1.0-M5 and I can't figure out how to 
create HttpEntity out of an ActorPublisher.

In short, I have ActorPublisher that produces a stream of events serialized 
as ByteString:

   class StreamSource(query: String) extends ActorPublisher[ByteString] ...

I am creating the Source from the companion object:

   object StreamSource {
 def apply(query: String) = 
Source[ByteString](Props(classOf[StreamSource], query))
   }

In 1.0-M3 I was able to create a HttpEntity for the Response with:
   
HttpEntity.CloseDelimited(mediaType, StreamSource(query))

But it breaks with 1.0-M5: the Source.apply[T]( props: Props) constructor 
creates Source[T, ActorRef] but all the HttpEntity constructors accept only 
Source[T,Unit]. The exact error is:

[error]  found   : 
akka.stream.scaladsl.Source[akka.util.ByteString,akka.actor.ActorRef]
[error]  required: akka.stream.scaladsl.Source[akka.util.ByteString,Unit]
[error] HttpResponse(200, entity = 
HttpEntity.CloseDelimited(mediaType, StreamSource(query)), headers = 
List(cors))

I have browsed the documentation and the sources for a few hours without 
finding a solution. So what is the currently supported way of creating 
HttpEntity instances with ActorPublisher source ?

Thanks in advance for any pointers,

luben


-- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups Akka 
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Secure-cookie not realy secure

[Любен Каравелов]

Hello,

I was looking these days about a light-weight transport authentication for 
akka remoting. SSL is heavy and could not authenticate clients as far as I 
understand the implementation in 
akka/remote/transport/netty/NettySSLSupport.scala. The other option that I 
was looking into is using akka.remote.secure-cooke. 

Today I dumped the communication and it looks that we pass the 
akka.remote.secure-cookie in plain-text over the wire. My look at 
AkkaProtocolTransport.scala confirmed that. I understand that this is not 
supposed to be strong authentication but still it is pretty weak one.

What I am proposing:

1. Add a configuration key akka.remote.cooke-digest with the name of the 
digest algorithm.

2. If it is not present - continue using the same logic as now: sending 
plain text over the network and textual comparison for verification. This 
guarantees backward compatibility.

3. If the cookie-digest key is defined:

- construct standard java.security.MessageDigest with the algorithm that is 
the value of the key

- use the secure-cookie value as a salt and compute a digest over the 
string representation of protocol + system + host + port

- use a textual representation of the digest value as a cookie value that 
goes into HandshakeInfo

- into Associate event processing construct the same text digest 
representation and compare with the received cookie in order to validate.

I am willing to implement the proposed change if you think it will be 
generally useful. It will not change the messaging protocol so I think it 
will be backward compatible. I will also backport it to 2.2 branch.

Do you think the proposed addition make sense? I am open to all kind of 
critique and suggestions.

Thank in advance,
luben

-- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: http://akka.io/faq/
  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups Akka 
User List group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/groups/opt_out.