I have a client-server setup which communicates via .NET remoting. We noticed after doing a netstat output on our server that the server had hundreds of socket connections to just one client. Once we shut down the client, the sockets, of course, disappeared.
I have built a small .NET remoting test server and client to see how extra sockets could be created via remoting. So far, I have found that since remoting calls are synchronous, the only way I could bind multiple ports was to make several different remoting calls in a multithreaded environment.
Our production client is not multithreaded during its remoting calls so seemingly, it only makes one call to the server at a time. My question is, does anyone know of a way in which .NET remoting would leave sockets open like this with only one client? Any configuration settings that might lead to this scenario?
Related
I'm looking for an open source alternative for commercial use to the RemObjects Remoting SDK.
I'm currently using Remoting SDK in the following scenario:
A number of windows service applications (5 to 10) act as servers and retrieve/provide data. These applications are developed using .Net Framework 4.6 (Windows service C#).
Several client applications (50 to 100) connect to each of the servers to consume the data provided by the servers. These clients are developed using .Net Framework 4.6 (WPF C#).
Remoting SDK RODL file defines the methods used by clients and servers to exchange data. Some of the methods are common calls that each client fires to retrieve data from the servers, some others are events that the servers fire and the clients receive automatically.
I would like to find an alternative open source library/framework to implement the communication between clients/servers in this scenario with the possibility to have both the clients calling the servers and the servers informing the clients when a certain event happens.
I have really basic knowledge regarding RPC and MESSAGE QUEUES and I've heard about gRPC, MQTT and RabbitMQ (which I've started to study in depth).
I would like to receive some suggestions/observations/links/guides by developers who are using one or more of these technologies in the .Net environment to solve scenarios like the one I've described to suggest me which solution will better fit the case.
I posted about this before to a degree, but after a few days of reading I have a better understanding of WCF and would like to get a bit of feedback before I start working on it.
I basically need to develop a server/client system. The "server" application (c# net console app) will be ran on a machine with a MySQL database, all software installation packages, and whatever else we need local to it. The "client" application (c# net console app) will be ran on the rest of our machines, and will maintain a direct connection to the server software. Using a web front-end, our administrators will be able to install software packages to the clients, create new services, etc.
Since we own all of the machines, and have to configure them anyways, Server Push is not a problem. We don't have to worry about firewalls or any sort of NAT settings as we can just go in and open the ports required for it to operate.
What initially confused me about WCF is I assocated a "WCF Service" with a server. However, since the majority of operations are actually going to be run on the "WCF Service", this is my logic.
1) Make the "client" application actually a "WCF Service" so that the exposed functions are actually ran on the proper machines.
2) Have the "server" application actually a "WCF Client", and issue all of the instructions/commands from here, and just use the return value to update the database/etc.
Would this be the proper method to go follow or should I look into WCF Duplex (Looked extremely confusing at first glance) or just start with raw sockets?
from what I gatther you're trying to do, you're correct. That is the client machines should really have a TCP/IP "server" running on them, and the centeral server machine would have the Tcp/IP "Client".
That way the TCP/IP client (The app running on your server machine) can initiate calls to each of the client machines.
Keep in mind also that a single application can be both a tcp/ip client and server. So your app that's running on the server machine could in turn also be a tcp/ip server that your admin uses to do stuff using a browser. Which effectively means that service is an HTTP service.
So, it is not a client/server thing. It is a hub-and-spoke arrangement of distributed computing. I think, WCF can very well be used. You have multiple servers and a coordinator (the client to all of these servers) that gets the work done from various servers and update the database.
So WCF is well-suited for you. The benefit of WCF is the easy configurability and handling the communication part. You don't have to take much pain for the management of sockets.
We are building a window service that starts/stops other processes, and the communication between the UI and the service is with NetNamedPipe.
Every process have a host that can get shutdown call (still with NetNamedPipe in order to avoid port cross).
I have used it on my computer and when I moved it to the server it didn't work (NetNamedPipe is not for cross network - now I know).
Is there any way to do this right?
If this is going to run on the local network, I would suggest using a TCP endpoint on your WCF service to connect to instead of the Named Pipe endpoint.
For .Net - to - .Net communication, it's best to use NetTcp. You would use Http when mixing technologies (.Net to COM / Java, for instance), or when a firewall would otherwise block your communication.
So Http is what you use only if there are reasons not to use NetTcp.
I'm about to write a "server" application that is responsible to talk with external hardware. The application shall handle requests from clients. The clients send a message to the server, and if the server is busy with doing stuff with the hardware the new messages shall be stored in a queue that will be processed later.
The client shall also be able to cancel a request (if it is in the server's queue.). When the server application is finished with the hardware it shall be able to send the result back to the client that requested the job.
The server and client applications may or may not be on the same PC. All development is done in .NET (C#) 2005.
What is the best way to solve this communication problem?
MSMQ? SOAP? WCF? Remoting? Other?
Assuming you can use .NET 3.0 or greater then you probably want to WCF as the communications channel - the interface is consistent but it will allow you to use an appropriate transport mechanism depending on where the client and server are in relation to each other - so you can choose to use SOAP or MSMQ or a binary format or others as appropriate (and can roll your own if needed). It also covers the need for two way communication.
Queuing the messages at the server should probably be regarded as a separate problem - especially given the need to remove queued messages.
If clients and server processes are on the same machine, I think named pipes will give you the fastest raw byte transfer rate.
If the processes are across different machines, you'd need to use sockets-based approach.
Remoting is reportedly very slow. Based on the target OSes that you're planning to deploy the solution on, you could have options like WCF et al. However, the overhead of these protocols is something you may want to look at while deciding.
Remoting
If all development is done in .NET 2005, Remoting is the best way to go.
MSMQ would make some sense, though there are then security and deployment considerations. You could look at a service bus (such s NServiceBus or MassTransit) and there's also SQL Server Service Broker that could help (and can also be used by a service bus as the transport).
WCF would be another thing to look at, however that's really the across-network transport, so you'd probably still want the WCF calls to put a message on the server queue.
I don't recommend remoting, because it's hard to maintain a separation of concerns, and before you know it you're developing a really chatty interface without realising it. Remote calls are expensive in relative terms, so you should be trying to keep the messages fairly coarse-grained. WCF would be my recommendation. Not least because you can set it up to use a HTTP transport and avoid a lot of deployment and security headache.
The .NET Framework provides several ways to communicate with objects in different application domains, each designed with a particular level of expertise and flexibility in mind. For example, the growth of the Internet has made XML Web services an attractive method of communication, because XML Web services are built on the common infrastructure of the HTTP protocol and SOAP formatting, which uses XML. These are public standards, and can be used immediately with current Web infrastructures without worrying about additional proxy or firewall issues.
Not all applications should be built using some form of XML Web service, however, if only because of the performance issues related to using SOAP serialization over an HTTP connection.
Choosing Communication Options in .NET helps you decide which form of interobject communication you want for your application.
I've written a client/server model in C# using .Net remoting. If I have the client connected to the server, then kill the server and restart it without trying to call any server methods from the client whilst the server is down, I can reconnect happily.
If I close the server then try to ping the server from the client (which I do from a separate thread to avoid an endless wait) then when the server comes back online, the client can never talk to it and my Ping thread that was fired during the downtime waits forever deep in the guts of the remoting libraries. I try to Abort this (if trying to Join the thread fails after a short time) but it won't abort. I'm wondering if this is part of the problem.
If I start up another client, then that client can talk to the server just fine. I figured I needed to restart some aspect of the original client but cannot see what would need to be shut down. I certainly null the server I'm connected to and call Activator.GetObject with the same address (something the second client does to connect to the server, which works fine), but re-getting the server doesn't help at all.
The server is running a as singleton via RegisterWellKnownServiceType.
I would start with wireshark and use it to see what is really going across the wire.
Is .NET remoting a requirement, or could you consider moving to WCF instead? The protocols are better factored and more clearly exposed when needed.
I was solving a similar problem. I had a working .NET remoting application using configuration files for the remoting and the routines of the .NET remoting I had to integrate into a larger application. I integrated this into the larger project, by the Activator.GetObject returned an instance of the proxy. As soon as there was a call of a member from the proxy instance, it ended up inside the member call and could not get off. The larger application contained various configuration files already thus the .NET remoting configurations I placed right there along with another configs for another thihs, and there was the crux of the matter. After I placed the .NET remoting configurations into a new empty config(s) file, the .NET remoting in the larger application started to work.