Add support for WebSockets

bikeoid commented 9 years ago

Make trolley location updates event driven by WebSockets / SignalR or equivalent technology.

jeremywight commented 7 years ago

This still would be fun. Any takers? :D

brbrown25 commented 7 years ago

@jeremywight I'm actually moving to Greenville at the end of the month and interested in getting involved with/learn more about this project. I'd be interested in working on this! I've had experience with websockets in java/scala backend in playframework as well as consuming on client side with jquery and javascript

jeremywight commented 7 years ago

Awesome! Join us next month for our monthly meeting Brandon, https://www.meetup.com/Code-for-Greenville/events/240482152/

On Tue, Aug 15, 2017 at 6:05 PM, Brandon Brown notifications@github.com wrote:

I'm actually moving to Greenville at the end of the month and interested in getting involved with/learn more about this project. I'd be interested in working on this!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/codeforgreenville/trolley-tracker-api-dot-net/issues/3#issuecomment-322602876, or mute the thread https://github.com/notifications/unsubscribe-auth/AH3RYFshIT5gLlR_zIcXtukb_bI-G0Ucks5sYhYegaJpZM4FpYMW .

bikeoid commented 6 years ago

At least 3 functions will benefit from Web Sockets to increase responsiveness while reducing traffic: o Running trolley positions o Stop arrival time updates (1 stop, all stops?) o Beacon updates (requires authentication and compatibility with client Android beacon app)

brbrown25 commented 6 years ago

When is your next meeting?

jeremywight commented 6 years ago

Tuesday

On Sat, Feb 10, 2018 at 4:03 PM Brandon Brown notifications@github.com wrote:

When is your next meeting?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/codeforgreenville/trolley-tracker-api-dot-net/issues/3#issuecomment-364706689, or mute the thread https://github.com/notifications/unsubscribe-auth/AH3RYCFiHtx0K8tHOQJo5bEekwMmobNTks5tTi5hgaJpZM4FpYMW .

bikeoid commented 6 years ago

Tuesday the 20th, that is. I won't be able to be at that meeting, but will be at the following hack night meeting on the 27th.

bikeoid commented 6 years ago

Stop arrival times will remain as a polled interface because it will be used rarely , while the estimated accuracy and update rate will be low.

brbrown25 commented 6 years ago

very cool, I actually was out of town during the last meeting for work but am definitely interested in contributing!

bikeoid commented 6 years ago

I started to look at some options to do this:

SignalR is the native ASP.NET server method, but notes about the Android SignalR library indicate flakiness.
Signal.io has some advantage because it is more robust and can easily fall back to polling if the client version of web sockets is incompatible with the server version. There are good libraries for Javascript, IOS and Android clients. However it has no native ASP.NET server version. There is an option to run Socket.io via iisnode on the server and on Azure - https://github.com/Azure/iisnode ; I don't know how reliable this is.
- Regular web sockets on both ends - This is probably the simplest in the end but there might be incompatible versions of Web Sockets between some old clients and our server. We'd just need to roll this out slowly to test.

Any other thoughts?

stampthecoder commented 6 years ago

I think the robust approach with Signal.io maybe best in this situation to be more reactive to situations where the incompatibilties may occur. Although, this may increase complexity by adding the said node on the server (more maintenance).

On Mar 1, 2018 10:27 PM, "bikeoid" notifications@github.com wrote:

I started to look at some options to do this:

SignalR is the native ASP.NET method, but notes about the Android SignalR library indicate flakiness.
Signal.io has some advantage because it is more robust and can easily fall back to polling if the client version of web sockets is incompatible with the server version. There are good libraries for Javascript, IOS and Android clients. However it has no native ASP.NET server version. There is an option to run Socket.io via iisnode on the server and on Azure - https://github.com/Azure/iisnode https://github.com/Azure/iisnode ; I don't know how reliable this is.
Regular web sockets on both ends - This is probably the simplest in the end but there might be incompatible versions of Web Sockets between some old clients and our server. We'd just need to roll this out slowly to test.

Any other thoughts?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/codeforgreenville/trolley-tracker-api-dot-net/issues/3#issuecomment-369809151, or mute the thread https://github.com/notifications/unsubscribe-auth/AGGpCp2bsaNJZt5BkUEv0ZEjHbJjeRY5ks5taLwIgaJpZM4FpYMW .

brbrown25 commented 6 years ago

In Java I've used the tyrus websocket client and a couple different on ios, and in dot net land I've used WebSocket4Net. I think regular websockets would be the way to go. I definitely agree a slow rollout would be best. maybe even adding it as an option that you could opt in to basically toggle between it using polling or websockets and provide a way to get user feedback on any issues. So maybe even seeing how WebSocket4Net works out compared with SignalR

bikeoid commented 6 years ago

Thanks - I was about to come to the same conclusion because node.js on the server end seems to be very sketchy to set up - too many separate setup steps which also complicates development testing and possibly problem troubleshooting if something stops working.

I think what we're doing is simple enough that plain web sockets will be OK. WebSocket4Net seems to be C# only, and might take more work on the IOS and Android implementation.

brbrown25 commented 6 years ago

Yeah I have had some painful experiences with node based microservices, definitely lots of issues can arise when deployment time comes. Would you like me to take a crack at adding a Websocket endpoint to the project with some tests?

Brandon Brown (240) 506-8335 (m)

On Mar 7, 2018, at 1:10 PM, bikeoid notifications@github.com wrote:

Thanks - I was about to come to the same conclusion because node.js on the server end seems to be very sketchy to set up - too many separate setup steps which also complicates development testing and possibly problem troubleshooting if something stops working.

I think what we're doing is simple enough that plain web sockets will be OK. WebSocket4Net seems to be C# only, and might take more work on the IOS and Android implementation.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

bikeoid commented 6 years ago

Yes, please go ahead and add a Websocket endpoint

brbrown25 commented 6 years ago

Sounds good will start working on that this week.

bikeoid commented 6 years ago

Update - Greenlink has requested that we use the API to the new system to get beacon information; that will allow them to discontinue the double cellular data subscription. So we will use the Web socket only for client location updates and not beacon information, and therefore doesn't need an authorization function.

ajhodges commented 6 years ago

There is a new system? That's interesting. Are they going to give us time to integrate/test out the reliability/accuracy of the new beacon? And if they have their own tracker does that make all of our work/frontends obsolete?

bikeoid commented 6 years ago

There was no time limit on the request yet - that does raise the question of obsoleting the entire Trolley Tracker application long term, since the new system has the same functionality.

Their beacon has been under test since 2nd half of last year; I don't know how reliable it is since they have just made the app public.

Speculating: I believe the reason they wanted to add the Syncromatics system to the trolleys even though there is already a trolley tracker is that it integrates the people counter and other management to track which stops are popular.

jeremywight commented 6 years ago

Yeah seems like it would be good to research what they have and make some considerations about how our product fits into this new system.

On Tue, Mar 20, 2018 at 2:23 PM, bikeoid notifications@github.com wrote:

There was no time limit on the request yet - that does raise the question of obsoleting the entire Trolley Tracker application long term, since the new system has the same functionality.

Their beacon has been under test since 2nd half of last year; I don't know how reliable it is since they have just made the app public.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/codeforgreenville/trolley-tracker-api-dot-net/issues/3#issuecomment-374705834, or mute the thread https://github.com/notifications/unsubscribe-auth/AH3RYGm-GGntwdOyEvcky6Y7t3lWRGTJks5tgUk2gaJpZM4FpYMW .

brbrown25 commented 6 years ago

I haven't jump far into this yet, is this something still worth adding?

bikeoid commented 6 years ago

Let's put this on hold until we get a view of the future since the basic functionality is already in the applications.

jeremywight commented 6 years ago

Yeah I agree. I'm traveling this week, but next week I'll see if we can setup a time to chat with Greenlink about this.

On Wed, Mar 21, 2018 at 9:08 PM, bikeoid notifications@github.com wrote:

Let's put this on hold until we get a view of the future since the basic functionality is already in the applications.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/codeforgreenville/trolley-tracker-api-dot-net/issues/3#issuecomment-375145402, or mute the thread https://github.com/notifications/unsubscribe-auth/AH3RYNtWhn9PnVb0yXwEynt2VZsT8iLZks5tgvmhgaJpZM4FpYMW .

jeremywight commented 6 years ago

Update: TL;DR - We are safe to proceed with Websocket work

We met with GreenLink last week and confirmed that they have no desire to replace the Trollery Tracker app and see it as serving a different market/user base. We will however begin transitioning and testing the location tracking from their other system. Thus we should continue with our plan to replace the client polling with websocket events.

On Thu, Mar 22, 2018 at 8:19 AM, Jeremy Wight jeremy@jeremywight.com wrote:

Yeah I agree. I'm traveling this week, but next week I'll see if we can setup a time to chat with Greenlink about this.

On Wed, Mar 21, 2018 at 9:08 PM, bikeoid notifications@github.com wrote:

Let's put this on hold until we get a view of the future since the basic functionality is already in the applications.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/codeforgreenville/trolley-tracker-api-dot-net/issues/3#issuecomment-375145402, or mute the thread https://github.com/notifications/unsubscribe-auth/AH3RYNtWhn9PnVb0yXwEynt2VZsT8iLZks5tgvmhgaJpZM4FpYMW .

brbrown25 commented 6 years ago

sweet, I'll carve sometime out this week to begin work

hackgvl / trolley-tracker-api-dot-net

Add support for WebSockets #3