These are chat archives for akkadotnet/akka.net

2nd
Feb 2015
Aaron Stannard
@Aaronontheweb
Feb 02 2015 01:33
@rogeralsing not tightly coupled at all
@rogeralsing we have the TestTransport which doesn't use Helios (or any kind of networking) at all in some of the unit tests
basically all you have to do is write your own Transport class and then register it in config somewhere
and it should get discovered and activated by one of the system actors inside the RemoteActorRefProvider
Aaron Stannard
@Aaronontheweb
Feb 02 2015 01:38
so as long as you implement that and whatever plumbing you need to connect your transport to the remoting actors (in the Helios case it's the tiny ChannelLocalActor class that does this)
you should be good to go
one caveat - you have to create a scheme identifier for each transport you create
I.E. the Helios transport uses the "tcp", "udp", or "ssl.tcp" scheme identifier depending on what transport modes have been enabled
on the Helios connection itself
you can't have more than one Transport active that use the same scheme
can't have two different TCP transports running in parallel
or whatever the scheme you use
because that scheme gets used inside all remote addresses
and must map 1:1 to a defined transport class
can't be 1:N
Aaron Stannard
@Aaronontheweb
Feb 02 2015 01:43
@avoxm I did have a chance to look at it - I was desperate to be able to avoid writing Helios when I needed good remoting support in Akka.NET back in the da
I don't have my notes in front of me, so I can't remember why I passed on it
also looked at XSocket (proprietary) and Kayak (abandoned)
Aaron Stannard
@Aaronontheweb
Feb 02 2015 02:00
I think it'd be great if we could get some more implementations of transports going as contrib projects - in particular I want to see some stuff like using RGP sockets (reliable multicast - used only in internal networks largely)
Avo M
@avoxm
Feb 02 2015 02:15
@Aaronontheweb I played with SuperSocket a bit last night
Aaron Stannard
@Aaronontheweb
Feb 02 2015 02:15
how'd you like it?
Avo M
@avoxm
Feb 02 2015 02:15
I have very small experience to have an opinion, but helios API makes you feel better :)
Aaron Stannard
@Aaronontheweb
Feb 02 2015 02:16
haha
here I was, feeling all insecure about the state of my socket library
and now you've made me feel better :partly_sunny:
I'm going to give Helios some love once we ship Akka.Cluster
Avo M
@avoxm
Feb 02 2015 02:17
haha .. it is a decent piece of code
it was a bit better then SuperSocket api but feels still immature
Aaron Stannard
@Aaronontheweb
Feb 02 2015 02:17
"Application framework for Business Applications"
Avo M
@avoxm
Feb 02 2015 02:18
yes but I used only network piece
Aaron Stannard
@Aaronontheweb
Feb 02 2015 02:18
one of the things that can be hard about creating general purpose libraries is coming up with good descriptions
that is not a good description :p
seems like it can do a lot of cool stuff though
Avo M
@avoxm
Feb 02 2015 02:19
well I was only interested in network lib, but yes it has bunch of stuff there
as for the helios Aaron I would say network framework is one of my immediate needs, so I do not mind to set some time to work on it regularly
Aaron Stannard
@Aaronontheweb
Feb 02 2015 02:20
thanks @avoxm
Avo M
@avoxm
Feb 02 2015 02:20
if you can open issues to share what is your vision on it
Aaron Stannard
@Aaronontheweb
Feb 02 2015 02:21
I'll try to make it easier for you to help on Helios
Avo M
@avoxm
Feb 02 2015 02:21
I would be happy to do the coding
Aaron Stannard
@Aaronontheweb
Feb 02 2015 02:21
that would be helpful for me too
ok, I'll make some progress on that
sounds like a good use of both our times
Avo M
@avoxm
Feb 02 2015 02:21
ok sounds like a plan !
I can start even from tomorrow
I went over the code it seems quite easy to follow
Aaron Stannard
@Aaronontheweb
Feb 02 2015 02:28
glad you feel that way :)
I'll start putting some issues together - and I have some diagrams explaining the new pipelined model
we're going to have to break a ton of stuff in Helios in order to pull that off
so this will be a major version change, 2.0
I've also thought through the threading / consistency guarantees I want to make inside the pipeline
and I'll move Helios to its own org next week
since I think that makes people feel less apprehensive about committing
Avo M
@avoxm
Feb 02 2015 02:35
That would be great
How close you want to follow netty ?
Aaron Stannard
@Aaronontheweb
Feb 02 2015 02:36
pretty closely - I'm following their pipeline design that way
but I think some of their stuff is janky and unnecessary
the way they do reusable byte buffers and the guarantees they make around their pipeline are good ideas
most importantly, I want to be able to implement something similar to their ChannelPromise model using the TPL
i.e. create tasks that are fulfilled when a message is sent, or when a specific message is received back
Avo M
@avoxm
Feb 02 2015 02:37
Yes that would be cool
Aaron Stannard
@Aaronontheweb
Feb 02 2015 02:37
adding a programming model that allows developers to do this will be useful
I don't care at all about supporting all of the different weird types of socket modes that Netty does
overlapped I/O using the async methods on TCP and UDP sockets covers 90% of use cases
probably closer to 99%
Avo M
@avoxm
Feb 02 2015 02:39
Well that kind of things will come from community needs and are not necessary to be there from day one
Aaron Stannard
@Aaronontheweb
Feb 02 2015 02:39
yeah
that's true
biggest thing I care about is the programming model
i.e. the pipeline stuff and the IChannelHandler modules
Avo M
@avoxm
Feb 02 2015 02:39
Agreed
Aaron Stannard
@Aaronontheweb
Feb 02 2015 02:39
and as a bonus, the TPL integration
we can add the bytebuffer stuff later
all of the fun reference-counting magic and that jazz :smile:
and as @jcwrequests pointed out, providing some sort of TLS support out of the box
would also be a great goal for 2.0
Avo M
@avoxm
Feb 02 2015 02:40
Also custom formatters would be great, I am not sure to want extend helios supports it now
Aaron Stannard
@Aaronontheweb
Feb 02 2015 02:41
I want to rewrite Helios' formatters as just IChannelHandler implementations
Avo M
@avoxm
Feb 02 2015 02:41
Yes TSL would be important and not that complicated at the same time
Aaron Stannard
@Aaronontheweb
Feb 02 2015 02:42
so you can use a frame-length handler, followed by a protobuff handler, followed by a handler that actually does stuff with POCO objects deserialized from protobuffs
so we should provide some handlers out of the box, like that frame-length one
or maybe a frame-delimiter handler
and add a contrib area for wire formats that people want to support
Avo M
@avoxm
Feb 02 2015 02:43
I see and it can be extended or replaced based on need
Aaron Stannard
@Aaronontheweb
Feb 02 2015 02:43
yeah, exactly
that's what is wrong with the current model - it's not as strong on extensibility as it should be
pushes a lot of that work into the end-user's app
when it can be a simple handler that the framework managers
manages*
Avo M
@avoxm
Feb 02 2015 02:44
Ok great, so when you think we can start pushing this forward
Aaron Stannard
@Aaronontheweb
Feb 02 2015 02:44
I think we can start next week
I'll start by publishing my diagrams and creating some issues
the diagrams aren't class diagrams, more abstract - like data flows
Avo M
@avoxm
Feb 02 2015 02:45
Nice, I guess that would be enough for me to start
Do you see it as rewrite or evolution over helios
Aaron Stannard
@Aaronontheweb
Feb 02 2015 02:46
(I might also have some code :p)
I see it as more of an evolution of Helios
the concurrency stuff and the collections, like the circular buffer and the IFiber stuff probably won't need to be touched
and the low-level stuff inside the IConnection classes that actually touch the network are still good
we really just need to replace all of the events that IConnection is wired to at the moment
and change the way data gets pushed from the network into people's apps
Avo M
@avoxm
Feb 02 2015 02:49
So I guess mostly, formatting / data massaging
Aaron Stannard
@Aaronontheweb
Feb 02 2015 02:49
yeah
my guess is that there's going to need to be some classes that manage pipeline instances for each connected client
and hang onto a message buffer for each of those instances
Avo M
@avoxm
Feb 02 2015 02:50
I think I saw something similar in griffin
And I have something simialr in my homegrown frw using concurrent dictionary
Ok I guess all is set for start... Give me a shout whenever you will have smth to start with
Aaron Stannard
@Aaronontheweb
Feb 02 2015 02:53
will do avo
Avo M
@avoxm
Feb 02 2015 02:53
Thanks buddy
Aaron Stannard
@Aaronontheweb
Feb 02 2015 02:53
send me an email at aaron@petabridge.com
I'll send you any of the detailed stuff there once I have my house in order :smile:
Avo M
@avoxm
Feb 02 2015 02:54
Lol it is never ending process man, house will never be in order ))
Aaron Stannard
@Aaronontheweb
Feb 02 2015 02:54
well, as in order as it needs to be for this to get started :smile:
Avo M
@avoxm
Feb 02 2015 02:54
Well, at least that's my experience
Ok cool