I want to make a client and server app. The client would be able to send a request and receive the relevant data that the server would make. The client would run on a single computer with a static IP address and the clients would run on multiple machines.
So far I've been trying to use Remoting but couldn't get it to work properly as all the examples I found seem to be old, is this the best way to enable this service or is there a better way to do this?
I used the answer that was posted by sipwiz on this question: How can I send data over the internet using a socket? , I modified the code to send and recive a serialized tuple and it works great for my needs.
Related
I want to create a simple messaging app that uses tcp protocol to communicate, including with multiple people. Messages get sent to the server, which distributes them to all other clients. At the moment, I have it fully functioning and it works perfectly - on a local computer and a local network, using the ipv4 address.
After an extensive Google search, I discovered that to communicate from a different network I need to port-forward my server. However, how do I make my server able to communicate with clients without all the clients port-forwarding? As far as I'm aware, not everybody's device is port-forwarded.
So, how do I implement this? Is it possible with just C#? Or did I misunderstand something, and port-forwarding isn't really required?
Thanks for all the help.
Why don't you use SignalR. I think it will be best for your problem.
First of all, my apologies for the most likely inappropriate wording of the question. Not knowing exactly how to describe the problem I need to solve has been a major roadblock in my attempts to solve it.
I currently have a web server (Laravel) that needs to communicate with a SQL server in a different network, which only permits outgoing traffic. I made it work by having a C# daemon, running inside the SQL server's network, poll it for data and send it to the server through HTTP POST requests.
However, I now need the web server to communicate with the daemon. Something as simple as:
someone looks up a username on the web server
the server requests the daemon to look it up on the database
the daemon returns whatever information it found to the web server.
What I'm struggling with is finding the best way to do this.
All I need is for the server to be able to push requests to the daemon in real time. The daemon can reply through HTTP POST requests to the server, just like it is doing already. The best potential solution I have found is WebSockets, but it also sound like it might be overkill.
Am I missing something or are WebSockets indeed the way to go?
Guzzle is what I use to make HTTP requests to external APIs in Laravel.
Websockets are mostly used when the user has no control over the responses, for example, a chat window. But if you need to, for example, click a button and wait for the response Guzzle is enough.
So I got as an assignment to make a small chat function where multiple clients should be able to connect to a server and communicate with it, the server should then be able to choose whom it wants to communicate back with. (From a dropdown list or something).
What I've been able to do so far, with help from some tutorials, is that clients can connect to the server and communicate with it but nothing more. The server can't communicate back.
I'm very new to this and have limited knowledge in both C# and TCP/IP.
https://gist.github.com/4565988 <-Contains both code for client and server.
So I what I need help with is a way for the server to reply to different clients and for the client to recieve a message from the server.
Any help is appreciated!
Best Regards, Fredrik
With regards to a starting point, I would have a look at WCF Duplex Services. Duplex allow you to subscribe to the service and send updates out using two-way communication.
Essentially you can create the server as a WCF service with a couple of methods: getclients and sendMessage. From there, a client can then subscribe to the service and (while connected) get a list of other subscribers (which you provide to the UI) and then send a message back to the service (which will then use duplexing to send it to whomever it needs to).
As long as you're not married to using sockets, this would be a lot easier than creating a protocol and managing a list of connections. There are also examples of using WCF as a chat medium available on code project.
For TCP knowledge I reconn Barbara Heckler's vid where she shows a brief implementation of such kind of server. Unfortunately in Java, but nevertheless very useful.
I reconn minute 0 - 15 for the basics (UDP) and 15 - 40 for the TCP connection and why mutlithreading is need for TCP but not for UDP.
http://www.youtube.com/watch?v=5QzNHEcLp10
It's pretty simple, really. That TCP stream you successfully extract and use to read what the client(s) sent can also be written to in order to send back something, so all you have to do is move the connection and stream objects out to shared collections of some sort so that your server-side sending logic can get at it when it wants to send something. Similarly, in the client you would issue a read on the TCP stream to read what the server sent.
I'm sure this has a simple work around, but right now I seem to have the inability to find an elegant solution. I have built an ASync C# server application which accepts multiple clients and handles them well, but to proceed I need to be able to determine which clients are connected to my server (there will be only two clients both of which do different things).
When my program accepts these clients I want the server to know the clients address and an indication which client is which potentially stored in a small list.
So I guess what I'm asking, is there a simple means of when the client has connected, sending a predefined message to the server letting it know what client application goes to which address?
Thanks
There are numerous ways.
One of the easiest is to have a different port for each of the client applications. The other way is in order to "connect" (after TCP Handshake) is to send a message identifying the application before any data is exchanged. The other option would be to add headers to each requests / reply stating the application and storing that.
You are free to send all kind of data over sockets.
To solve this, invent some kind of protocol between client and server.
For instance sending a first message when connecting to identify the client to the server.
From there on continue with the normal conversation between those two.
Server can accept the message and store of show it, or even reject the client when the first message does not contain the agreed information.
I'm looking to develop an asynchronous C# TCP server which can act as a proxy between two client VNC connections, passing data between the two transparently.
I've already got some asynchronous client-server code set up where I can effectively communicate messages between the server & any connected clients, now I need a way to host a kind of proxy for VNC traffic.
Client A--------------Server--------------Client B
VNC traffic sent -> relayed through server -> VNC traffic received
And then any response from client B to simply flow back to the server, then transitively to client A.
If any more information is required for a proper answer, please do let me know.
Thanks!
I managed to get this answered on Server Fault...the key is to launch "socat" from your application and use it to "link" the connections together.
See: https://serverfault.com/questions/254855/socat-connect-connect-proxy-two-inbound-tcp-connections-to-expose-a-firewalled
For more information.
You say that you already can receive data on the server that is sent from the client - you just write exactly what you read from one client back out to the other connected client.
It seems like you've already done the hard work, and I'm confused as to what part you're not understanding on how to finish it up.