Is there some successor to netchan?

[Bienlein]

Hello,

is there some replacement for netchan based f.ex. on an approach as described in this blog? Maybe some framework "that does it all" with some nice simple interface :-) ?

Thanks, Bienlein

[DisposaBoy]

... didn't read the blog ... haven't used it... but the closest thing to netchan I can think of is https://github.com/kylelemons/fatchan

[Kamil Kisiel]

I haven't had a chance to try it yet, but you might want to take a look at Go Circuit: http://www.gocircuit.org/

[Kyle Lemons]

On Tue, Oct 8, 2013 at 10:11 AM, DisposaBoy <dispo...@dby.me> wrote:

... didn't read the blog ... haven't used it... but the closest thing to netchan I can think of is https://github.com/kylelemons/fatchan

Yep, I specifically designed fatchan as an experiment to see if I could make something like netchan, but that would work over any ReadWriteCloser and which could actually send working channels over those channels.  I wouldn't really suggest using it in production, but it's a reasonably good way to add a process/network boundary into existing code if you are testing it out.

The big problem is that errors are out of band, because channel communication itself cannot fail.  Wiring the out-of-band errors up correctly enough for this to be stable in production is a challenge I haven't undertaken, and suggestions about API changes to make it easier would be accepted with gratitude.

Docs, examples, etc: http://godoc.org/github.com/kylelemons/fatchan

 

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Kevin Gillette]

On Tuesday, October 8, 2013 12:45:45 PM UTC-6, Kyle Lemons wrote:

The big problem is that errors are out of band, because channel communication itself cannot fail.

I recall this as being the primary reason netchan was deprecated, though I think it's not as much of an issue as it would seem; flag.ContinueOnError and friends provide something of a precedent for how to approach the problem. I would think a good API would involve creating a network context, and per context being able to define how errors are handled. Some options would be: 1) ignore error, blocking indefinitely until reconnection occurs, 2) close the runtime channel (if on the read side, no apparent error, otherwise, will panic on the next send), 3) register an additional `chan error` to receive connection errors on, the receiver of which can call methods on the context for custom behavior (the first two could just be sensible defaults, ala default signal handlers, that are implemented in terms of these methods).

[Kyle Lemons]

On Tue, Oct 8, 2013 at 12:45 PM, Kevin Gillette <extempor...@gmail.com> wrote:

On Tuesday, October 8, 2013 12:45:45 PM UTC-6, Kyle Lemons wrote:

The big problem is that errors are out of band, because channel communication itself cannot fail.

I recall this as being the primary reason netchan was deprecated, though I think it's not as much of an issue as it would seem; flag.ContinueOnError and friends provide something of a precedent for how to approach the problem. I would think a good API would involve creating a network context, and per context being able to define how errors are handled. Some options would be:

I agree, which is why my API allows you to give it a function that will be called on errors :). 

 

1) ignore error, blocking indefinitely until reconnection occurs,

fatchan doesn't specify a transport, so there is no such thing as a reconnection.  You can make your own ReadWriteCloser that does transparent reconnection, of course.

 

2) close the runtime channel (if on the read side, no apparent error, otherwise, will panic on the next send),

This can be handled by closing the Transport or closing the channel in the error handler.

 

3) register an additional `chan error` to receive connection errors on, the receiver of which can call methods on the context for custom behavior (the first two could just be sensible defaults, ala default signal handlers, that are implemented in terms of these methods).

I thought about this, but I decided on the function because the only time you could create/register such a second channel would be when the initial channel is created... all future channels sent/received over that channel would produce indistinguishable errors. 

[Kevin Gillette]

On Tuesday, October 8, 2013 2:27:38 PM UTC-6, Kyle Lemons wrote:

I thought about this, but I decided on the function because the only time you could create/register such a second channel would be when the initial channel is created... all future channels sent/received over that channel would produce indistinguishable errors.

I thought about you thinking about that: being able to define independent contexts (though in your case, it'd be per ReadWriteCloser), means that the straightforward approach of one error channel per context means that such errors won't be indistinguishable. Further, including in each error a reference back to the originating context would allow the application to use a combined channel for multiple contexts while still being able to determine the source of errors.

To facilitate transparent reconnection, the context implementation should allow the ReadWriteCloser to be swapped out (during a safe state, of course) without closing the exposed channel.

[Kyle Lemons]

On Tue, Oct 8, 2013 at 1:47 PM, Kevin Gillette <extempor...@gmail.com> wrote:

On Tuesday, October 8, 2013 2:27:38 PM UTC-6, Kyle Lemons wrote:

I thought about this, but I decided on the function because the only time you could create/register such a second channel would be when the initial channel is created... all future channels sent/received over that channel would produce indistinguishable errors.

I thought about you thinking about that: being able to define independent contexts (though in your case, it'd be per ReadWriteCloser), means that the straightforward approach of one error channel per context means that such errors won't be indistinguishable. Further, including in each error a reference back to the originating context would allow the application to use a combined channel for multiple contexts while still being able to determine the source of errors.

If you could create an issue with what you think such an API might look like, I'll think about it :).

 

To facilitate transparent reconnection, the context implementation should allow the ReadWriteCloser to be swapped out (during a safe state, of course) without closing the exposed channel.

I'm afraid you can't do that, because in addition to what gob has assumed has already been received by the other end, fatchan also makes a lot of assumptions about what's already been received by the other side.  Replacing the rwc would require that these invariants remain, and if that's possible, you might as well just implement that in the underlying rwc.