Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Mar 17 2015 02:57
    Petabridge-CI commented on 6d69b19
  • Mar 17 2015 02:56
    Petabridge-CI commented on 6d69b19
  • Mar 17 2015 02:54
    Petabridge-CI commented on 6d69b19
  • Mar 17 2015 02:53
    Petabridge-CI commented on 6d69b19
  • Mar 17 2015 02:30
    Aaronontheweb opened #20
  • Mar 14 2015 22:12
    Petabridge-CI commented on e9fe745
  • Mar 14 2015 22:10
    Petabridge-CI commented on e9fe745
  • Mar 14 2015 22:10

    Aaronontheweb on dev

    added contributor guidelines Merge pull request #19 from Aar… (compare)

  • Mar 14 2015 22:10
    Aaronontheweb closed #19
  • Mar 14 2015 22:10
    Aaronontheweb closed #14
  • Mar 14 2015 19:07
    Aaronontheweb opened #19
  • Mar 11 2015 01:16
    Petabridge-CI commented on 94b7064
  • Mar 11 2015 01:15
    Petabridge-CI commented on 94b7064
  • Mar 11 2015 01:14
    Petabridge-CI commented on 94b7064
  • Mar 11 2015 01:13
    Petabridge-CI commented on 8806511
  • Mar 11 2015 01:13
    Petabridge-CI commented on 94b7064
  • Mar 11 2015 01:13
    Petabridge-CI commented on 8806511
  • Mar 10 2015 21:13
    Petabridge-CI commented on 94b7064
  • Mar 10 2015 21:12
    Petabridge-CI commented on 94b7064
  • Mar 10 2015 21:12
    Petabridge-CI commented on 94b7064
Aaron Stannard
@Aaronontheweb
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
Max Gortman
@nayato
oh, my thinking was in a different direction
I wonder if using SendAsync and ReceiveAsync would be more appropriate
Aaron Stannard
@Aaronontheweb
would you mind explaining that some more?
Max Gortman
@nayato
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
Aaron Stannard
@Aaronontheweb
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
for virtually every metric
it's hard to parse the difference going into WinSock calls
Max Gortman
@nayato
yeah, it generates less garbage and has less synchronizations in code path
Aaron Stannard
@Aaronontheweb
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
Andrew Skotzko
@skotzko
This is a pretty slick lil UI. Hey fellas.
Max Gortman
@nayato
@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.
Max Gortman
@nayato
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.
Aaron Stannard
@Aaronontheweb
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
Max Gortman
@nayato
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
Aaron Stannard
@Aaronontheweb
@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
also going to spin Helios out into its own org
and document my plans for it
so I won't be the only one who can fix it
Andrew Skotzko
@skotzko
:thumbsup: