Documentation and Comments

[NVentimiglia]

Some very basic documentation defining the key features of NetGains would be nice. Looking at the code I see support for HeartBeat (kicking dead connections), an serverside interface for handling disconnections, authentication, and messages. I also see a UserToken, is this some sort of client session? Its hard to tell because none of the methods have comments.

Also maybe a WebApi / MVC serverside demo would be nice

[lbacaj]

A JavaScript demo would also be nice. The library looks like a really promising alternative to SignalR which is somewhat heavy and has a dependency on jQuery still baked in it for JavaScript clients.

[mgravell]

What I'm hearing is: "we need to see an end to end typical use case". I get
that. This seems a reasonable request. Any suggestions for examples? Maybe
a very simple chat style application (no storage, auth, etc)?

On Fri, 19 Feb 2016 14:50 Luljan Bacaj notifications@github.com wrote:

a javascript demo would also be nice.

—
Reply to this email directly or view it on GitHub
#3 (comment)
.

[NVentimiglia]

@mgravell yeah that would be awesome. Like @Ibacaj I am looking for something like SignalR without the bloat which makes SignalR completely unusable for game development.

For my case I need a concept of channels / groups (send to a subset of users). and Presence (broadcasting when a user disconnects). Looking at the code, I noticed the Broadcast method accepted a func for sending to select users. I also noticed the heartbeat. Am I correct to assume this is a possibility for NetGain ? If so, it would be great if you included this.

Not needed, but nice to have would be some sort of user state. Something like userName, I didnt see an extensible point for the connection, maybe there is another way ?

You mentioned Auth and storage. Agree they are not needed, but some pointers on how to go about this (Dos and Donts) would always be welcome.

Also, I would be happy to help with a demo on the client side (Xamarin or Unity or Mvc or whatever) once a interface is ready.

[pjanning]

A simple chat client with user to user communication, and examples with SSL would be nice.

[mgravell]

Re state: that is all built in; there is an object (UserToken) that you can
stick anything you like on, and populate at auth time.

Broadcast can indeed be used to talk to a great many nodes; you can pass a
predicate that returns a message or null to not notify that client.
Alternatively, if you track individual connections, you can just send
explicitly to the ones that interest you.

We use NetGain as part of chat.SE, so it all sounds possible.

What we DO NOT currently support is SSL (wss). We haven't needed to.
I'd be open to pull requests that added that, but at the moment we use raw
sockets, not a Stream, so it would be quite a significant piece of work to
do that. I wonder whether that is something that would be better handled by
haproxy or similar, if possible.

On 22 February 2016 at 15:37, pjanning notifications@github.com wrote:

A simple chat client with user to user communication, and examples with
SSL would be nice.

—
Reply to this email directly or view it on GitHub
#3 (comment)
.

Regards,

Marc

[NVentimiglia]

@mgravell is this UserToken shared between client and server or will I need to come up with a handshake ?

[pjanning]

I am looking forward to see examples. :) Depending on your implementation WSS/SSL isn't needed. Do you have more informations about chat.SE?

[NVentimiglia]

I have a non-working sample. I may be doing something wrong on the client side, I'm not a native JS speaker.

https://github.com/NVentimiglia/NetGain/tree/master/StackExchange.NetGainWebChat

My exact error is

SyntaxError: Failed to construct 'WebSocket': The URL '127.0.0.1:6002' is invalid.

Ill try again later

[pjanning]

SyntaxError: Failed to construct 'WebSocket': The URL '127.0.0.1:6002' is invalid.

Try to use 'ws://127.0.0.1:6002' as URL. This should work.

[NVentimiglia]

WebSocket connection to 'ws://127.0.0.1:6002/' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED

That got me further. My firewall is off, anything else you can think of ?

Edit

Worked fine when I ran the console app independent of the web app. It would be nice to run within the web app for prototyping without a VM.

[NVentimiglia]

@mgravell Is there any way to handle onconnect / ondisconnect serverside ?

[mgravell]

The typical usage would be to subclass WebSocketsMessageProcessor; this
then allows you to override various methods, including methods that relate
to each WebSocketConnection (as a parameter), such as:

OnOpened
OnAuthenticate
OnAfterAuthenticate
OnClosed
OnShutdown

Does that answer the question?

On 1 March 2016 at 03:34, Nicholas Ventimiglia notifications@github.com
wrote:

@mgravell https://github.com/mgravell Is there any way to handle
onconnect / ondisconnect serverside ?

—
Reply to this email directly or view it on GitHub
#3 (comment)
.

Regards,

Marc

[pjanning]

@rherwig and me built a little example with NetGain. Here are our Repositories:

https://github.com/pjanning/NetGain-ChatExample/ (Backend)
https://github.com/rherwig/websocket-chat (Frontend build with React)

[mgravell]

nice; awesome stuff

On 2 March 2016 at 07:46, pjanning notifications@github.com wrote:

@rherwig https://github.com/rherwig and me built a little example with
NetGain. Here are our Repositories:

https://github.com/pjanning/NetGain-ChatExample/ (Backend)
https://github.com/rherwig/websocket-chat (Frontend build with React)

—
Reply to this email directly or view it on GitHub
#3 (comment)
.

Regards,

Marc

[pjanning]

@mgravell I have one question. Why don't you need WSS at StackExchange?

[mgravell]

In a perfect world, we'd probably make use of it, but basically we considered:

• wss is awkward to implement from the technical perspective, especially if you are working from the socket layer, not the stream layer (so: you can't just use SslStream)
• tying our web-socket server security into the primary site security (with rotating cookies and all that goodness) is awkward
• we don't want to send big payloads to unattended browsers
• we deploy the web-socket server very rarely, contrast to the web-site which we deploy very frequently; since we want the UI elements (and any associated data) to reflect the up to date site, it makes sense to let the web-site deal with that (assuming it can't be done trivially in javascript)

So basically, in our scenario, the optimum approach seems to be: only broadcast a "hey, there's more stuff you should know" (not the actual stuff, just a hand wave "hey you!" - no PII in there, note). Trivially simple (and public) stuff like rep / voting: we just update on screen from that, but in most cases we display a notification to the user that new stuff is available (which could be a red inbox envelope, or a "new questions / answers are available" banner). When the user actually clicks on that, we use regular AJAX to our main site with our regular security model etc.

In other scenarios, I totally agree that wss would be not just desirable but necessary. The problem is: it isn't a small amount of work to do it!

Now; on a related note, I suspect that if we want to move to .net core, some massive changes (aka basically a rewrite) would be necessary. Whether that is sensible or not, I don't know at this point - it could well be that the reduced API surface in .net core means that it simply doesn't scale in the way we need. And there are now more and better tools in this space than existed when we first wrote this. But hypothetically, if we were gutting it for .net core purposes that forced us to use different APIs, that might also be a good time to consider wss. Or maybe it isn't! But I certainly can't think of any clean way to implement it right now.

[mgravell]

@pjanning To expand on that, @NickCraver has reminded me that we do use wss, but: not at the library level. We terminate that at the NLB (haproxy). The library does not support wss, but it can still be done externally. We didn't use wss initially, hence the above.

[NickCraver]

To add to the WSS discussion, because this is important: we don't use WSS for security at Stack Overflow. Nothing of a secure nature is sent over them.

We use WSS because a great many (especially older) proxies on the internet do not handle websockets connections correctly. While most of these will totally screw up an unencrypted websocket connection, they'll happily pass along an encrypted connection they don't understand. It's a "bad proxy" workaround in our case, and for many others out there.

[pjanning]

Thank you for your answers. @NickCraver, @mgravell

I was really confused, how you could use NetGain at StackExchange. If i set up an Webpage which is accessed via SSL. I have to use WSS. Otherwise i would not get an connection. Your solution to use a proxy for this sounds good. Thank you!

[jalchr]

How does this http://vtortola.github.io/WebSocketListener/ fit against NetGain ?

[jalchr]

@pjanning @mgravell
This repository no longer exists https://github.com/rherwig/websocket-chat

Any hints about how are you sending initial data (for example, username or so ) on initial connection (for example onOpen or On Authenticate) ?
Or I'm getting this totally wrong, and I'll have to wait until "OnReceive" to get an useful identification from the client ?!