4

The requirement is to provide duplex communication methodology between .net client application which is a windows application and javascript application, which runs on the browser.

Flow is 1. User installs the client app on their machine. 2. User visits the website and logs in to the portal which hosts the javascript app. 3. If the user performs an activity on client .net app, javascript app requires to be notified. 4. If the user performs an activity on the javascript app on the browser the .net client application has to be notified.

Possible solutions tried out are 1. Web server .net client app, where javascript app connects to using web sockets. However given the .net client app might start the webserver on a different port than originally intended, if the ports in use, the javascript app might not be able to identify the port the web server is running on. 2. Have an activeX running on the javacript app. Both the active X and .net app will connect through local named pipes through WCF. Bad part is use of active X will show a pop up soon as you load the web application.

Would you know of a better solution for the problem?

Ajay
  • 18,086
  • 12
  • 59
  • 105
user3614386
  • 119
  • 1
  • 10

2 Answers2

4

We've successfully used WebSockets for duplex communications between in-browser Javascript and an external app running a WebSocket server. It's efficient and (at least as of last year) bypassed all browser sandbox restrictions. I'm not 100% understanding this part of your question:

However given the .net client app might start the webserver on a different port than originally intended, if the ports in use, the javascript app might not be able to identify the port the web server is running on

The .NET app can run a socket server on any port it wants. If you are writing both apps, I'm not seeing how synchronizing on a specific port would be an issue? Worst case scenario the desktop app could write the port to local storage, which your JS can grab via local storage. There are other ways to synch this as well.

  • If the designated port, is used by another application(usually wouldn't) the .net socket server will fail to start up and will require to start up on another port. This could be reproduced if you start the app on a machine, and do a switch user, on another user and start the app again. .net client would realize the port is in use and would have the choice of not starting the server or choosing another port. In which case there is no mechanism for the javascript app to be notified. – user3614386 May 08 '14 at 03:28
  • This is why I mentioned local storage :) .NET app can write "active port I'm serving on" as a local storage setting. Javascript can read the same from local storage when it connects. Any medium that the .NET app can write to and the JS app can read does an end-run around this issue, no? My question would be: can we solve this *without* the metadata. –  May 08 '14 at 03:33
  • I missed the part where you said save to local storage. How do I access the local storage from java script? – user3614386 May 08 '14 at 03:34
  • I would start here: http://stackoverflow.com/questions/4692245/html5-local-storage-fallback-solutions. In practice it's simple to read from and write to, the complication is browser compatibility. There are shims available if you need this to run on, eg, IE8 or something :) but as of latest browsers I believe it's solid. –  May 08 '14 at 03:37
  • Thanks will read up. I am not able to up vote the answer since I dont have enough rep yet. Will mark it as the answer as I dont see other ways. – user3614386 May 08 '14 at 03:40
  • No worries. If somebody suggests a way to do this without the additional overhead, I would mark that as the answer. Another couple options here: the JS could open a connection to the socket server, issue a message, and if it doesn't get an expected response, it would know to fallback to its secondary IPs/ports. Sort of a poor man's "handshake". In this case you wouldn't need local storage, but your fallbacks would have to be predefined and agreed on. Another idea, probably overkill, is to call a locator service over WebSockets. That then returns the WebSockets application server verifiables. –  May 08 '14 at 03:42
  • cant see a method of accessing the local storage mechanisms that javascript can write to by .net windows application. – user3614386 May 08 '14 at 04:39
  • poor mans handshake would work though. will wait for another day to see if anyones got any better. I really would like to communicate through pipes, which would be ideal. Ill porbably go with webrtc p2p and write a layer on top of it. wish they had pipes too. – user3614386 May 08 '14 at 04:42
  • On FF and Chrome (for example) local storage is just a SQLite DB. Load/create it via System.Data.SQLite as you would any other DB. http://stackoverflow.com/questions/9669184/how-is-html5-webstorage-data-physically-stored/ –  May 08 '14 at 05:52
1

SignalR is a communications API that has client libraries for both .NET and javascript, and the server library is built on the ASP.NET stack.

With it, you can build a solution that allows client (js) <-> server <-> client (.NET) communication.

Here are some useful links to get you started:

Community
  • 1
  • 1
Andrew Vermie
  • 623
  • 3
  • 8
  • This would have worked if the web application which was hosting the javascript app was developed by me. The hosting web app is developed by another party, where I only develop the javascript app which they would include on their site and initialize. – user3614386 May 08 '14 at 03:30