How can I find out in code client's app (C#), which technology (polling or WebSockets) is used to communicate with the server?
From your hub you can call the following:
Context.QueryString["transport"]
It will return one of the following values: "webSockets", "serverSentEvents", "foreverFrame" or "longPolling".
I would say that your code shouldn't depend on which transport is being used, but it's might be useful in some cases (logging etc).
Related
I'm looking for an open source, cross-platform, actively maintained .NET library which provides websocket functionality for both clients and servers, in such a way that most of the code (after connection is established) can use the same abstraction regardless of which side of the connection it is on. Ideally, it would be a platform-independent implementation of System.Net.WebSockets, but I don't really care if it defines its own types, so long as there's some single abstract WebSocket class that can be shared by client and server code.
Things that I've looked at and that did not qualify (but correct me if I'm wrong):
System.Net.WebSockets (client only, Win8+ only)
WebSocket4Net (client only)
WebSocket Portable (client only)
Fleck (server only)
WebSocketListener (server only)
SuperWebSocket (server only)
Owin.WebSocket (server only)
PowerWebSockets (proprietary)
XSockets (proprietary)
Alchemy Websockets (last release in 2012, many active bugs in the tracker with no answers)
The only one that I could find that seems to be matching the requirements is websocket-sharp. However, what worries me there is the sheer number of opened issues in the tracker along the lines of clients unable to connect, invalid data frames etc - it sounds like it's not very mature yet.
Are there any other candidates that match my requirements that I have missed? Or am I wrong about any of the libraries listed above being client/server only?
Look at Microsoft's SignalR. SignalR is a higher level abstraction around websockets. SignalR also allows the client to be written in .NET (C#). From the SignalR documentation:
The SignalR Hubs API enables you to make remote procedure calls (RPCs) from a server to connected clients and from clients to the server. In server code, you define methods that can be called by clients, and you call methods that run on the client. In client code, you define methods that can be called from the server, and you call methods that run on the server. SignalR takes care of all of the client-to-server plumbing for you.
SignalR also offers a lower-level API called Persistent Connections. For an introduction to SignalR, Hubs, and Persistent Connections, or for a tutorial that shows how to build a complete SignalR application, see SignalR - Getting Started.
One another solution is to make use of Edge.js. This is a .NET library that utilizes Node.js. You could let Node.js to act as both the server and client of the WebSocket channel. And then utilize Edge.js to act as the bridge between the worlds, Nodejs and the .Net. Have a look at the following, there are plenty of samples as well. github.com/tjanczuk/edge/tree/master#scripting-clr-from-nodejs. Both are excellent frameworks that are actively maintained.
However the use of Edge.js does introduce an additional dependency, node.js
You can take a look at the WebSocketRPC. The library is based on the System.Net.WebSockets and it is portable. Moreover, it auto-generates JavaScript client code and has support for ASP.NET Core.
I suggest you try-out samples first located inside the GitHub repository.
Disclaimer: I am the author of the library.
Background
I have multiple servers that I currently connect to remotely to run a number of different commands/scripts to obtain information about the servers and/or applications running on the servers.
I'd like to automate running the commands/scripts (or the code contained in the scripts converted to C#/.NET) and have the server send alerts/notifications/messages to a client (basically a Windows Form) running on multiple workstations, but need some guidance.
For reference, I have limited experience creating Windows Services, but feel fairly confident in being able to create them on the server to handle to command/script automation, which I'm assuming would be the best way to go about handling the command/script automation on the server (since the commands/scripts would need to be run all the time or at set intervals).
Question
How can I connect multiple servers to multiple clients so that the server sends alerts/notifications/messages to the client when a command/script or even an event occurs on the server?
For instance, if an application on the server has a built-in command that can be run to determine the status of the application (up, down, limbo, etc.), I would like the Windows Form on the client to receive an alert from the server when the command returns "down" or "limbo" when it is run, presumably from a Windows Service. The alerts would be displayed on the Windows Form that would be setup basically as a dashboard for the servers that the client can connect to.
An even better outcome would be that the client runs as a background application and a notification appears similar to how Microsoft Outlook displays a notification when new email messages arrive (although these notifications would likely require user interaction to close instead of fading out like the Outlook notifications).
I would also like for the client to use a configuration file that has the connection information for the servers in it so that the servers being used can be changed quickly new servers are added or existing servers are decommissioned.
Research (so far)
I've read about WCF and duplex contracts, and how WCF can be hosted in Windows Services. From what I've read, this seems promising. However, I'm not quite sure how I would set this up so that the client can connect to a WCF service on multiple servers.
One thing that I'm concerned about with WCF is that in all of the WCF examples (which implement a calculator-type service) I've seen the client has to initiate the communication with the server in order to receive a message through a callback. In the calculator service examples, the client sends numbers to the service and the result is provided in the callback. I've also seen an asynchronous example, but in that example the client initiated a single, long running request and the callback returned a single response when it was finished processing.
And, just so I'm clear about bindings in WCF, it is possible to create and use bindings for multiple servers using a configuration file without having to use SvcUtil.exe to generate the code, correct? The reason I ask is because the servers that will be configured will likely be change for different users, so the client needs to be flexible when connecting to the services.
I've just now started looking at Sockets, but I'm not familiar enough with them to know if this would be the better option to achieve my objective.
Summary
I'm just looking for guidance, so if you can help direct me to some resources that will help me achieve my objective, I would appreciate it. I've searched extensively, but the majority of my searching either doesn't apply to my scenario, it is limited to a single server/client interaction, or it is limited to a single server with multiple clients.
Since I'm not sure what direction to go in, I don't have any code examples, although I have implemented the examples in the following Microsoft article: Windows Communication Foundation - Getting Started Tutorial
So you want to build a system of
multiple servers which execute commands on the computer they are running on
multiple clients which will receive the status of the commands executed on server or such information from the server
This would be my advice
Servers can be implemented as windows service. You will be able to administrate them easily this way using the services console or the scm. Checkout this link for a creating a simple C# service How do you write and use a Windows Service in C#?
Also, you can set the service to run as an in-built service user with different levels of permissions in addition to regular user accounts.
I have not used WCF, but usually clients connect to the server; this is a pretty common model, and hence all samples are such. Initiating connection from server is not a big deal (at least in a socket program), but just a bad model. You have to ask yourself, if no client is connected to your servers, how can they relay a status to the end user. You have to think clearly about the communication model. I would suggest a central repository of messages. It can be a file on a shared file system or a database or any such entity which can act as a data repository. This way all servers can convey there messages without caring if a client is connected or not. You can use Sockets to achieve what you want to do. Check the asychronous socket server sample from MSDN to understand how to do it.
Making the client run in the background and just have a notification area icon is also easy in c#. You can use NotifyIcon Class for that. This CodeProject article (Formless System Tray Application) demonstrates its usage. To show notification a la outlook style, you can refer to the following post: How to create form popup from from system tray on windows application (not web) with c#. Look at not only the accepted answer but other answers too; there are lot of useful links in it.
So far we have windows service talking over sockets, storing messages in a central repository and capable of handling multiple clients with toast style pops for client side notification.
You need a far richer client side GUI so the end users can take actions on the messages sent from the server. You can maintain a list of servers in app.config for the client that the client connects on startup. You should to provide a GUI for users to manage all servers and their connections.
Lat but not least, by building such a client server model, you are effectively building a security loophole in your systems. You should implement a good authorization mechanism. Checkout the following post: Authenticate user in WinForms (Nothing to do with ASP.Net)
EDIT:
You can also implement your server to accept "custom command" when you implement it as a service. This way, your client server communication will be standardized by using ServiceController to pass the command. This post might help: How to send a custom command to a .NET windows Service from .NET code?.
Don't get confused in the "command" terminology here. ServiceController issues standard commands to a service for start, stop, pause, resume and restart the service. These are the same items you see on the context menu when you right click a service in the services.msc snap-in. The same way a service can respond to custom commands. In your case the custom command maybe a request to execute a process.
Note that some mechanisms I have described are geared towards an intranet setup while others scale fine on both intranet and internet
Is it possible to implement client/server communication between a C++ program (client program) running in linux OS with a C# program(server program) running in Windows using RMI implementation?Can anyone suggest any possible way...Any kind of helpful reference is welcome
You would need to go along the lines of Google Protobuf. It is available with C++ and C# as well.
A similar answer from MSDN
It does not matter if you send data from java,c++ or c#, when it goes
over the network it's just 1s and 0s. It's a matter of what you do
with it on the client/server side. So, be sure that the data that you
receive corresponds with the structure that you have (that you want to
deserialize to).
Sometimes you need to manually put the bits and bytes together to get
it all working out. However, there is something called "Protobuff"
that can help you get a common structure of the data that you send,
google it and read all about it.
You can implement client server with sockets and serialize/deserialize it using protobuf.
(MSDN link might help in solution)
I think message passing libraries would fit best in to this. Take a look at ZMQ for instance; they have binding for many languages found here
so you may have your event dispatcher in one language and listener in the other language. Also take a look at apache thrift
CORBA is one IPC mechanism that will provide the RPC mechanism that you are looking for.
Here is a link describing communication between C# server and JAVA client.
http://iiop-net.sourceforge.net/dnAdderRmiClient.html
At one of the companies I worked previously, it was used for communication between c++ and java programs in a client/server model.
They used a combination of ACE/TAO libraries.
http://www.cs.wustl.edu/~schmidt/TAO.html
I would recommend that you do not use remote method invocation for communication between a client and a server. In the nineteen-nineties we used to believe that RMI is a good idea, but since then we have realized that there are much better ways for communication between computers.
The most popular way is by using Web Services, and the easiest flavor of Web Services is RESTful Web Services. (Look them up.) This has the benefit of not caring at all whether the runtime environment of the client looks anything like the runtime environment of the server, as the case is with your setup, where your client is C++ on Linux and your server is C# on Windows.
Mozilla's XPCOM might be your bridge. There is also PyXPCOM. Realistically though the easiest way is to have an intermediate VBox. So you run a VBox instance (running Windows) on the linux machine and then use VBox API (from C++) to issue commands within VBox. So you end up with
Linux <--xpCom--> VBox <--COM--> Windows
When working over network it's protocol what matters, not the client/server.
In telecommunications, a communications protocol is a system of rules that allow two or more entities of a communications system to transmit information via any kind of variation of a physical quantity. These are the rules or standard that defines the syntax, semantics and synchronization of communication and possible error recovery methods.
Source Emphasis is mine.
So, in order to communicate your C++ client and C# server you need to choose or define protocol that will be used for communication.
Your protocol can be build above another protocol. For example, you can use HTTP for transportation purposes and define your protocol describing what syntax should be used for messages in HTTP requests and responses bodies. This will help you, because there're many ready-to-use solutions for HTTP communication.
Actually you will build your protocol based on another anyway. HTTP itself build above TCP. You'll need to choose whether it would be low level or high level protocols. They all have their pros and cons.
But you will have to deal with messaging between your client and server yourself.
As an alternative you can use some Remote Procedure Call(or RPC) solution:
Remote procedure call (RPC) is an inter-process communication that allows a computer program to cause a subroutine or procedure to execute in another address space (commonly on another computer on a shared network) without the programmer explicitly coding the details for this remote interaction.
So that means that you only have to follow guidelines how to build your client and server and all communication will be hidden and will look like as just calling object's method.
Source
Here's short list of possible RPC solutions:
Component Object Model with DCOM. Wiki: COM,DCOM. MSDN: COM, DCOM.
Simple Object Access Protocol. Wiki.
Windows Communication Foundation. Wiki. MSDN. SO(credits to Sanju for link).
To wrap it up:
It's not a problem that your client and server are in different environments and are developed using different platforms. You only have to build communications between them using either your own messaging system based on some protocol, or some RPC system.
We could just write a C# program to listen messages from a particular port and write another C++ client program to write message to that port.As thus we could communicate both application.
In a previous solution, I recall setting up code-behind-type hub connections for unit testing. I believe I used code from the previous SignalR Hubs C# Client GitHub wiki.
In the SignalR Hubs API guide there is an example of using a console-based client:
stockTickerHubProxyProxy.On("Notify", () => Console.WriteLine("Notified!"));
In an upcoming application there will be notifications to be pushed to several clients. Some of these clients will be UI-based (JS), and others, will be some back-end code that will perform some task.
I am familiar with the JS-based client connectivity. My question centers around attaching code-behind-type clients, and how their methods "notified".
I understand that with a UI-based client, the mechanism is to push the update to the client through dynamic invocations to client-side "methods". Since it's been a few months since I've touched SignalR, what is the best way to accomplish this where there is no UI involved?
To verify that I am understanding the documentation correctly , when valid transport method is used, a C#-based (non UI/JS) client is notified (push) through the SignalR framework - no client polling required?
The essential mechanism is the same for JS and C# clients. The solution is exactly what you mentioned in your question. The 'On' method will subscribe the client to any "notify event" triggered by the server. You can refer to the documentation to get a better understanding:
http://www.asp.net/signalr
I will need to begin development on an Android applicaiton soon. This application will need to communicate with a server over the internet. I hope to be able to do my development in C# in one of the various development environments that appear to be available, e.g. Mono for Android.
My questions are:
What is the best framework for developing C# applications for Android?
What will give me the most flexibility for communicating over the Internet? (My boss tells me that existing c# --> Android frameworks have limitations regarding internet access)
What are the limitations that I can expect to face doing this with C#?
What are your experiences with taking this approach?
For communication over internet there might be many ways, depends on your needs.
It can be HTTP requests with some POST data, or proper low-level communication over Sockets.
If you need to communicate with web service that accepts POST requests and provides some data in XML (for example), then you might use HTTP request way.
If you have real-time server that servers Sockets communication, then you might want to use Sockets with some data protocol over it (based on which data protocol server accepts / serves).
There is full support for establishing Sockets communication using MonoDroid with. It is almost the same as with x86 .Net implementation on Windows.