This topic has been discussed million times before, but let me clarify my needs:
I need a single server which controls a system and includes the necessary functions. Furthermore, there will be "n" Clients which represents only the HI/GUI and call server side functions. The server itself should be able to send data back to the clients and call client-side functions too (like shutdown, exit and so on...)
I have heard about duplex services/contracts (http://msdn.microsoft.com/en-us/library/ms731064.aspx), but I'm not sure how far I'll come with that.
How would you handle this?
I recently made a proof of concept app that made both the server and the client host a WCF service each. The client connects to the server and then in a handshake call, gives the server the connection information to allow the server create a separate connection back to the client. It worked a treat with multiple clients on network links from local lan to 64k line on remote sites at the same time.
You could use WCF, and host the service on the server in IIS, in the application on the client and let the client register it's endpoint on the server.
Related
I have a .NET application which sends PHP GET and POST requests to my server (on an AWS EC-2 instance).
I now have a need for the local application to know in real-time when an event on the server happens.
Basically two "accounts" are linked and they need to synchronize, so when one makes a change on the server, then the server must send a signal to the other to update it's "view".
I'm aware that I could achieve this by constantly querying to server to check for changes, but that seems horrendous.
Could someone please point in the right direction here?
Thanks!
Certainly you could use signalR, signalR can be hosted like website, when your client starts it can connect to this signalR website. SiganlR should be hosted separately from your server application.
Let say A,B client and your Server application got connected to signalR. Now when A modifies something using post method to your PHP server, PHP server then can invoke a method in signalR , then signalR can broadcast message to all the clients connected. You can use group concept in signalR to target specific audience.
I want to develop sock5 proxy server in c# which could make connections to client.
i.e in normal scenarios client or browser make connection to proxy server but i want the proxy server to connect to the client.
i googled a lot but could not find any code sample in c# or other language.
This sounds like a rather broad question, but generally I think what you are trying to do isn't "by definition possible". Socks5 is defined in RFC1928 (https://www.rfc-editor.org/rfc/rfc1928). It specifically relates to the 'client' connecting to the 'server'. In order for the proxy server to connect to the client, the client machine would have to have some form of service running and listening on a previously established port (assuming TCP/IP here). I suppose you could write some form of browser plugin or a service daemon to listen for server initiated connections; however, this wouldn't technically be 'socks5'. Having an open port (service) on your client open other security concerns, such as a connection from a machine claiming to be your server, or an outside machine requesting the proxy server to contact your client machine. Part of the trust model of these setups is the idea of client initiated actions. You may be trying to solve the wrong problem (i.e. you may need to reframe your problem in a different way).
We are planning on implementing our new software application as shown below.
Does this architecture look fit for purpose?
Items to Note:
There are many PC's
The pc has a WCF client as it needs to upload data to the
database periodically.
The PC has a server because the end user on the terminal server needs
to be able to interrogate the pc for information
The terminal server is the GUI for users so they can remotely connect
to a specific PC to interrogate the pc for information
We are using basicHttpBinding below
What else have we considered?
We have tried WCF NetPeerTcpBinding (i.e P2P) but it does not support
request-reply operations.
We have tried WCF Duplex but with the requirements listed above in the items to note section we would end up with a client and server at both ends anyway.
Well I apologize but I basically disagree with your architecture.
WCF is not designed or suited for anything other than a request-response communication.
Its full duplex ability will not enable your server side to issue communication to a specific client unless that client already issued a connection to the server.
That means that in order to achieve a prestigious online full duplex communication with all your clients - all your clients must maintain an open port to the server.
Having a dual client and server per PC in order to achieve an online full duplex is a step forward as it will solve the issue of keeping a port open per client however it has downsides in terms of security as it means that the specific PC is open to receive multiple connection requests. Another issue can occur with deadly reentrancies if you not careful. So, basically you will be saving 'ports' in exchange for architecture
maintainability and fitness to your solution.
So if you are targeting a deployment of around 200-300 PC's your architecture will hold but if you are targeting a larger deployment of thousands of PC's - it will not hold.
I have a C# applications which acts like a client and it can be installed on any system which is directly connected to public internet (through data cards or port forwarding) or they can be behind router also (without port forwarding).
The other application which is developed using java acts like a server application which is on the public internet. Now, my java application wants to push a message to C# application which is behind router. Java application has the clients public and private (192.168.x.x) IP address. Java application is supposed to run 24x7.
So, now there are two options for me:
Whenever c# application starts it will establish a socket connection with java application and this socket connection will remain open till C# application gets closed.
Whenever Java application has something for C# application it will create a socket connection with C# application then it will push the message and then close the connection.
Now, with 1st option there is a problem that there will be lots of unnecessary connection since there can be thousands of client application and it may happen that on some day there will be nothing to push for some clients. and I don't know how to go for 2nd option.
What will be the right way to accomplish this task (option 1 or 2)?
Is UPnP protocol right for 2nd option? What are the open source UPnP libraries which has both the API's (C# and Java). I found one such called ohnet. Will it be a right thing for me? I didn't found a single small example for OhNet to test.
2) is not feasible if you don't have control over network configuration at the client end. It won't in general be possible for the server to make connections to the client if the client is behind any moderately secure firewall / router.
So you will in general have have to go for some variant of 1) where the client creates a connection to the server.
You don't necessarily have to keep the connection open though - it's always possible to get the client to poll the server periodically to check if there are any new updates.
If you want realtime updates to the client from the server then you will still need to keep a connection open. This isn't necessarily a problem if you use Java NIO you should be able to handle tens of thousands of simultaneous incoming connections relatively easily.
Using option 2, will you have to queue messages for your C# client until it connects? That could make your Java application run into out of memory problems if the C# application doesn't connect.
I would definitely use method 2 by adding a static route in the router (port forward). You should - however - ensure that the server behind the router is protected from the rest of your network (DMZ).
UPDATE:
Perhaps I have missed something here (method 1 or 2) :-) - but just to make it absolutely clear: It is always the client that should initiate the connection to the server. And yes, you could allow the client to request the server for updates on a regular basis.
The TIBCO EMS .NET reference guide says (pg 134)
To enable reconnection behavior and fault tolerance, the serverURL parameter must be a comma-separated list of two or more URLs. In a situation with only one server, you may supply two copies of that server’s URL to enable client reconnection (for example, tcp://localhost:7222,tcp://localhost:7222).
The TIBCO EMS user's guide (pg 292) talks about failover scenarios, client notification, and automatic transfer of clients to the backup server, but nothing specifically "reconnect" related.
In a "reconnect" scenario, does the server handle everything? or does the client have to do something with it's TIBCO.EMS.Connection instances?
Looks like from our testing that the there are settings on both the server and the client that enable this feature. On the client side, the SetReconnAttemptCount, Delay, Timeout govern the attempts the client tries to reconnect once its aware of a server failover / connection failover.
In our testing, we used a single server environment, listed the server twice in the connection string (using the trick you outlined above) and when that server was taken offline, we received a client notification of the failover process taking affect (we enabled Tibems.SetExceptionOnFTSwitch(true)) and when the server was brought back online, our client seemlessly reconnected without missing a beat. We didn't need to code anything, the internal reconnect logic worked its magic.
On the server side, fault tolerance needs to be enabled and I believe server-client and client-server heartbeats need to be enabled (though this has not yet been verified).
Hope this helps.