I have a number of WPF clients on the same corporate network. I want these clients to share messages with each other. I don't want to run a separate server process so a brokerless solution would seem best. I have considered using PNRP but this seems to require a PNRP service to be running on each client, I'm not sure I could guarantee all the clients would or could be running this. I have also had a look at ZeroMq which looks ideal it terms of simplicity and its very lightweight, however I would need to know the endpoints for a TCP/IP style communication and each client won't be aware of the others rather they need someway to discover each other. So essentially I want a multicast style of communication but without having to use multicast since this will require me to get a range of addresses set up within the corporate network and involve infrastructure etc.
So I guess the question is are there any options I haven't considered that fit the bill?
Thanks in advance for any help.
The ZeroMQ pub-sub pattern is simple and fast until you reach hundreds of clients; you can switch to a real multicast protocol then (PGM) without modifying your application.
Perhaps you should check out NServiceBus. It is a true service bus, so no broker machines in the middle. It runs on MSMQ so your windows servers will support that out of the box. It also supports transactional messaging. It also supports a pub/sub model that should satisfy your multicast requirement.
If you don't mind using a commercial product: OMG's Data Distribution Service is a standard with several implementations that can do what you are looking for. At least one of them supports C# and does not require anything to be installed on your machines -- just the libraries. Disclosure: I work for this company.
So essentially I want a multicast style of communication but without
having to use multicast since this will require me to get a range of
addresses set up within the corporate network and involve
infrastructure etc.
DDS by default uses UDP/IP over multicast for discovery and communication, but can be instructed programmatically or via configuration files to use UDP over unicast only, or TCP. This does not affect application logics, so the conceptual multicast nature is preserved. However, if you do not have IP multicast at your disposal then you will lose some out-of-the-box automatic discovery features. In this case, you would need to know in advance the IP addresses or host names of all nodes that could potentially participate in the communication. From there, the middleware will be able to discover who of these is actually present and adjust its communications accordingly.
I think the latter is true for any solution you choose though. For fully automatic discovery, you will need either multicast/broadcast, or some known discovery server(s) running in your system.
We've written a peer-to-peer message bus, Zebus, based on ZeroMQ (transport), Cassandra (peer discovery and persistence) and Protobuf (serialisation).
It is open source and production tested https://github.com/Abc-Arbitrage/Zebus
Zebus is being actively developed and it is in heavy in-house production use. Currently there is only a .NET language binding but as the OP mentioned that he only had WCF clients this should meet his needs.
Have you considered the peer to peer protocol for WCF? See here for more details: http://msdn.microsoft.com/en-us/library/cc297274.aspx
ZeroMQ is a good choice for this. To solve the discovery problem, stand a server that every client checks in when starting and stopping. This server can also be running ZeroMQ as both a publisher and subscriber.
The clients publish to one port on the server, which binds a subscriber to that port to get check-in and check-out messages. The server in turn publishes those messages on another port (which it also binds) to which the clients subscribe.
Related
I've 7 processes hosted on same machine (C# .NET Framework), each of them is wrapping a NServiceBus (gateway) endpoint to communicate with remote-site processes (MSMQ-based Transport, InMemroyPersistency).
I was wondering if from performance/network utilization aspect, should i split each endpoint to use it's own port or can all of them share the same port for the gateway ReceiveChannel definition?
Thanks
By default the gateway use the HttpChannel with a concurrency set to one. Assuming you set the concurrency per channel to something feasible that fits your use case and given that the implementation is non-blocking you are only restricted by how much throughput a single HttpListener that is used under the hood can handle.
Given that each endpoint should have its own responsibility in terms of handling/processing messages and therefore potentially needs to fulfill its own Service Level Agreement you might want to have more control over how to expose those endpoints. That being said from the gateway perspective port sharing should be possible and I would suggest do run load tests according to the requirements you have for you project to make the right tradeoffs.
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.
So many programs in the past and even the present operate on a Server/Client basis. Examples include TeamSpeak, Ventrilo, Mumble, etc. These programs typically require going into the router and forwarding ports so that the computer running the server can get the messages from the clients which are sending connection requests to the server's router.
Is there anything in WCF these days that allow you to prevent that sort of thing? I have a chat/file transfer program and I would really prefer that users not have to know how to forward their ports.
What kind of options are there out there in the way of UPnP or Punchthrough? The notion of having to go through and forward all the specific ports that a program uses seems so outdated.
Have a look at WS-Discovery with WCF:
http://weblogs.asp.net/gsusx/archive/2009/02/13/using-ws-discovery-in-wcf-4-0.aspx
The discovery protocol negates a central, "server router" as you put it. It's uses UDP broadcast to notify clients of each other.
Note that the discovery protocol itself is just a stateless messaging protocol. It has no guarantees or state synchronization. If for example, Client A doesn't receive the broadcast message from Client B, then Client A wont know of Client B. The protocol overhead of maintaining this P2P states is complex and usually a single server to hold this state is the easiest approach.
I have a windows service (.net) that is an implementation of a custom protocol. I need monitor this service from multiple desktop clients (packets arrived, rejected, error, and things like that).
I'm evaluating different alternatives (remoting, socket multicast, etc), but I like to know if this problem have and standard solution. I think this is a very common scenario, if you think in services like IIS, serviced components, etc., you can connect remotely from many clients at the same time and manage the service.
I appreciate suggestions and examples.
Thanks in advance.
SNMP.
Quote from wikipedia (I've highlighted the interesting part):
Simple Network Management Protocol (SNMP) is an "Internet-standard protocol for managing devices on IP networks. Devices that typically support SNMP include routers, switches, servers, workstations, printers, modem racks, and more.”1 It is used mostly in network management systems to monitor network-attached devices for conditions that warrant administrative attention
C# implementation: http://www.snmpsharpnet.com/
A simple implementation is to use Custom Commands.
You would then be able to use WMI to administer the service with your custom commands.
I need to create a system comprising of 2 components:
A single server that process and stores data. It also periodically sends out updates to the agents
Multiple agents that are installed at remote endpoints. These collect data in (often, but not always) long-running operations, and this data needs to get to the server
I'm using C# .NET, and ideally I want to use a standards compliant communications method (i.e. one that could theoritically work with Java too, as we may well also use Java agents in the future). Are there any alternatives to web services? What are my options?
The way I see it I have 3 options using web services, and have made the following observations:
Client pull
No open port required at the agent, as it acts like a client
Would need to poll the server for updates
Server push
Open port at the agent, as it acts like a server
Server must poll agents for results
Hybrid
Open port at the agent, as it acts like both a client and a server
No polling; server pushes out updates when required, client sends results when they are available
The 'hybrid' (where agents are both client and server seems the obvious choice - but this application will typically be installed in enterprise and government environments, and I'm concerned they may have an issue with opening a port at the agent. Am I dwelling too much on this?
Are there any other pros and cons I've missed out?
Our friends at http://www.infrastructures.org swear by pull-based mechanisms: http://www.infrastructures.org/papers/bootstrap/bootstrap.html
A major reason why they prefer client-pull over server-push is that clients may be down, and clients must (in general) apply all the operations pushed by servers. If this criteria isn't important in your case, perhaps their conclusion won't be your conclusion, but I do think it is worth reading the "Push vs Pull" section of their paper to determine for yourself.
I would say that in this day and age you can seriously consider only pull technologies. The problem with push is that clients often are hidden behind Network Address Traversal devices (NAT) like wireless routers, broadband modems or company firewalls and they are, more often than not, unreachable from the server.
Making outbound connections ('phone-home'), specially on well known ports like HTTP/HTTPS can basically be assumed as 'possible' even under most constricted networks.
If you use some kind of messaging server (JMS for Java, not sure for C#) then your messaging server is the only server that needs to open a port and you can have two way communication from your agent to the messaging server and from the server to the messaging server. This would allow you to accomplish the hybrid model without needing to open a port on the agent server.
IMHO, I find your best option is the pull option.. that can satisfy your main system requirements as follow:
The first part: Data needs to get to the server, that's obviously can be done through invoking a web method that send that data as a parameter
2nd part:(Server periodically sends out updates to the agents): You can still do that that thru client (regular) pulls by some sort of a web service method that "asks" for the updates since its last pull (some sort of s time stamp to get the updates it missed)
The hybrid method seems a bit weird to me given that I think of an agent as a part of the system that probably might go "offline" quite often, what will the server then do if that failed? it's usually a tough question/decision, specially if you're not sure if this an intended "going offline" or a system/network failure.. etc