I'm evaluating that possibility for Helios 2.0 right now
I'm wondering about the possibility of being able to allow developers to create their own promises (TaskCompletionSource) that their apps can wait on for general purpose duplex communication
kind of like how the HTTP client does under the hood in .NET 4.5
so in this case, if they were building a socket client using Helios
and let's say the transport was over UDP
I'd like them to be able to create a promise that an app (which would consume the Helios client) can wait on while the Helios client sends a message to a server and the promise gets completed once a response is received
wondering about a concrete way of doing that now
Netty, which Helios is modeled after, has ways of doing this but they're pretty janky
oh, my thinking was in a different direction
I wonder if using SendAsync and ReceiveAsync would be more appropriate
would you mind explaining that some more?
I wonder if using ReceiveAsync, SendAsync would be beneficial from performance perspective
instead of Begin/EndReceive
advantage there is that "result" object (SocketAsyncEventArgs) can be reused
compared to BeginReceive where it's generated on per-call basis
ah, is that the only major semantic difference?
because technically I think either could work - all I really care about for the receive side of the equation is inverting control over to an I/O completion port
on the Send side of the equation
I've always gotten better results with synchronous sends
it's hard to parse the difference going into WinSock calls
yeah, it generates less garbage and has less synchronizations in code path
I'll have to check it out then - haven't really profiled that area as thoroughly since I made a bunch of structural changes to it for Helios 1.3
most of the performance improvements came from redoing the Executor and the EventLoop
This is a pretty slick lil UI. Hey fellas.
@Aaronontheweb hey, how do you actually plan to support TLS? the only serious implementation of TLS on .NET is SslStream and its API seems incompatible with netty's ChannelHandler.
also, I see messages being lost in client when receiving. here's gist for both client and the server: https://gist.github.com/nayato/d7d9b82d9adbc8272f3c . Problem seems worse on slower machines, e.g. on my desktop I see occasional loss of up to 500 messages, while on Medium VM in Azure it's 65k out of 100k messages. Probably I'm doing something wrong here.
I've had three folks approach me about message loss issues with Helios in the past 24 hours, too many to bea coincidence
so clearly there's an issue in the way we do some of the reactive socket stuff
here's what I'm going to commit to doing - I have to wrap up some work on the Akka.NET V1 release
but as soon as that's finished, moving forward on my plans for Helios 2.0
it's going to be a major change designed to introduce a better API, but most importantly much stronger concurrency and consistency guarantees around the socket
because right now I don't think it would be easy to patch the current model as-is
BTW, running the same pair of client and server I posted I get NRE:
Unhandled Exception: Helios.HeliosException: Unhandled exception on a connection with no error handler ---> System.NullReferenceException: Object reference not set to an instance of an object. at Helios.Net.Connections.TcpConnection.SendInternal(Byte buffer, Int32 index, Int32 length, INode destination) --- End of inner exception stack trace --- at Helios.Net.Connections.UnstreamedConnectionBase.InvokeErrorIfNotNull(Exception ex) at Helios.Net.Connections.TcpConnection.SendInternal(Byte buffer, Int32 index, Int32 length, INode destination) at Helios.Net.Connections.UnstreamedConnectionBase.Run() at Helios.Ops.Executors.BasicExecutor.Execute(Action op) at Helios.Concurrency.Impl.DedicatedThreadPoolFiber.<SpawnThreads>b_1(Object ) at System.Threading.ThreadHelper.ThreadStart_Context(Object state) at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Threading.ThreadHelper.ThreadStart(Object obj)
I can repro that (inconsistently but quite often) only on Azure Medium VM
@nayato same here, had this happen a lot during multi-node tests
as soon as we get Akka.NET V1.0 to code complete this will have my full attention