Develop Reference

StackExchange Redis .NET client not getting messages when connections are reordered

Using the StackExchange.Redis client in a C# application, I am attempting to use PubSub to perform cross-server communication between web servers running the same application. In this model, each server is running its own Redis server, and its connection multiplexer sets the local server as the first server in the list. In other words, SERVER_A and SERVER_B each run a Redis server on port 6379 and have connection strings as follows:
SERVER_A --> "SERVER_A:6379,SERVER_B:6379"
SERVER_B --> "SERVER_B:6379,SERVER_A:6379"
Using external clients to subscribe to each Redis server, I can see SERVER_A publishing messages to its local Redis server. However, SERVER_B is not picking up the message, despite having a connection via the multiplexer. When I rearrange the order of the connections so they match, then messages from A are picked up by B. Is there something in a setting or otherwise that I need to do so that the connection multiplexer will listen to subscriptions on all servers, or is this a bug in the StackExchange.Redis client?

You don't mention any replication in your description. When SE.Redis connects to multiple servers it is intended to be a related family of servers - for example, either:
two or more 2.* servers related via master/slave
three or more 3.* servers related via a formal cluster
Replication groups have distribution mechanisms for pub/sub. Two disconnected servers: do not.

Initiating tcp connection from public IP to private machine on another network

I'm having difficulty finding help resources on this. I know how to use the TCPClient class to create a connection between one IP/Port/machine and another.
My doubt is how does that work when one machine wants to initiate a TCP connection to another machine where the destination machine is inside a different network. So the destination network may have hundreds of computers each with its own private ip and the network would have one public IP address. This would be using the TCPClient class or any other that is more appropriate.
I know we could use ports and then inside the network the port could be forwarded to the correct machine but I was looking for a solution like the one services like LogMeIn use. Basically I wanted to use port 80 always and then initiate the connection from the server to that particular machine or others on the same network when I needed.
I suppose, theoretically, I could create the connection first from inside that network, then on the server, save the details and close the connection and then in the near future, when I needed, I would re-open the connection.
So in my scenario, I would have many clients across multiple networks, each network might have multiple internal machines with a client installed. Then on the server I would initiate connection to these machines when needed. Within each network I would want to use port 80 for obvious reasons. The reason I want to initiate the connection from the server and not the client machines is simply to save resources, I couldn't cope with having opened connections until eventually I might need to communicate wit them.
Also, I have no control on the client networks besides them having my client installed.
Ideally, I wish to have c# info, possibly code and not network configuration.

I had this requirement at a previous company. We installed our client/server software (C# based) on numerous different networks with a mix of public/private IPs. I found two relatively simple ways to solve it. First, I want to say that without a public IP, its impossible to connect reliably (in my experience).
When I proposed the solution, I explained the problem to other developers/managers this way.
Your server, the machine with the public IP address [public to clients, but may still be an "internal address"], is like a house without any long distance calling. It can receive calls, but it can't make any calls. The clients are like houses with long distance service. Clients must call the server, because they have long distance. Once connected, any party can talk on the line.
From here you have two choices.
Client connects and never disconnects (this is what I implemented). On the server, I had an object that mapped the client object to the client connection so I could communicate any time with a client that was connected.
Server holds a queue of messages for the client. The client automatically connects on a fixed interval to see if there are any messages (maybe 5 minutes). There would be an option from the server to stay connected for a specific interval. Another vendor called this "fast talk".

There's a couple of approaches.
You could setup NAT - probably no good for your scenario.
You could make an outbound connection from your client.
You could "combine the above" by using STUN (see http://en.wikipedia.org/wiki/STUN) this is quite popular in VOIP for peer to peer scenarios.

The Windows Azure servicebus may have a solution for your problem; NetTcpRelayBinding in hybrid mode allows two comuters behind NAT to create a direct connection with each other. This might not solve your problem if you are money constrained as each connection has an associated cost.The simplest solution is probably to have the clients polling your server.

You may use SignalR, which has been developed for this kind of scenarios.
You must have a third party, though (a server which broadcasts messages from sender to other peers).
But the beauty of this technology is that it chooses the most appropriate way to push data to clients: Polling, long connections, sockets... etc.
This provides an abstraction layer which is quite comfortable.
It has been designed to interact with javascript clients, but may be used in full-C# clients as well.

You need a third server that acts as proxy between your machine and target machine that is behind a firewall.
That is how applications like LogMeIn work.
You can do this using SSH tunnels.
Please check https://serverfault.com/questions/285616/how-to-allow-remote-connections-from-non-localhost-clients-with-ssh-remote-port

The topic is about NAT traversal.
STUN is good choice to try to communicate with client behind NAT.
But if STUN don't work,you can use RELAY service to help to pass the message between your server and remote client.RELAY service is a public service that everyone can reach it.

Reverse Connecting Sock5 Proxy server c#

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).

WCF architecture help needed

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.

Client-Server architecture

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.