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.
Related
I have TCP server and clients written in C#. Since my connection is over wifi which is not reliable, I use resending the same packet and handle packet loss.
For example a bank account platform. The user deposites money and the client send this message to the server, if the server received this message, it will reply the client the operation is successful. If the client doesnt receive the reply, it will send again after a period of time.
This looks simple but I faced a situation when the wifi stucks and the client didnt receive reply and keep sending the same message to the server. End up those messages were received by the server at the same time. As a result the server thought the user deposites money 100 times.
I would like to know usually how people handle such case for tcp server client program, especially when the application is not just a chat application, but more sensitive information like money. My first thought is adding a transaction ID in the message so the server will not handle the messages with the same transaction ID, which will prevent the above case. But not sure if there is any better solution or .Net has some internal function for this.
Thank you.
When you code in C#, you are mostly working from within the Application layer of OSI model. TCP protocol works on the Transport layer (which is below the application layer).
Reliability, that you want to achieve, is already embedded inside the TCP protocol itself. This means, it will attempt to resent the packets, if some were lost, automatically without your additional requests. This will also happen before control is returned to the application layer program. There are also other guarantees, such as ordered delivery of the packets.
This means, that the functionality you need is already implemented at the layers bellow and you don't need to worry about it.
Note, if you were to use UDP, you would need to handle reliability problems yourself.
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 trying to build a simple multithreaded tcp server. The client connects and sends data to server, the server responds and waits for data again. The problem is I need the server to listen for incoming data in separate thread and be able to send command to client any time (for example to notify about new update). As far as I understood, when ever client sends data to server, if server doesn't respond with any data, client app doesn't let me send more data, server simply doesn't receive them. If I send data ether way around, does the data need to be 'acknowledged' for tcpclient?
Here's the source for the server: http://csharp.net-informations.com/communications/files/print/csharp-multi-threaded-server-socket_print.htm
How can I make the server send command to a client in separate thread outside the "DoChat" functions loop? or do I have to handle everything in that thread? Do I have to respond to each request client sends me? Thanks!
The problem is I need the server to listen for incoming data in separate thread
No, there is an async API. You can polll a list of threads to see which ahve new data waiting, obcviously to be done froa worker thread.
As far as I understood, when ever client sends data to server, if server doesn't respond with any
data, client app doesn't let me send more data, server simply doesn't receive them.
That is a lot more crap programming than the way sockets work. Sockets are totally ok with streaming ata in sending and receiving direction att the same time.
How can I make the server send command to a client in separate thread outside the "DoChat"
functions
Wel, me diong your job costs money.
BUT: The example is retarded. As in- totally anti pattern. One thread per client? You will run into memroy problems and perforamnce problems once 1000+ clients connect. You get tons of context switches.
Second, the client is not async because it is not written so. Mayy I suggest giong to the documentation, reading up on sockts an trying to build that yourself? THEN come back with questions that show more than "i just try to copy paste".
With proper programming this is totally normal. I have a similar application in development, sending data lall the time to the client and getting commands from the client to modify the data stream. Works liek a charm.
If I send data ether way around, does the data need to be 'acknowledged' for tcpclient?
Yes and no. No, not for TCP - TCP does it'Äs wn handshake under the hoods. Yes, if your protocol decides it has to, which is a programmer level design decision. It may or may not be necesssary, depending on the content of the data. Sometimes the acknowledgement provides more information (timestamp server side, tracking numer) and is not pure ly there for "I got it".
I need some feedback with some programming logic.
I'm developing a TCP Server using C#, which will also act as a TCP client. Basically, a client device (A) contacts my TCP Server and sends information. Based on that the TCP server may (or may not) talk to another server (Z) over TCP, send some data to it and sometimes get a response which it passes back to device A. So far so good, this works quite well. However, sometimes Z creates a new connection to my C# TCP server, and wants to send some data to device A.
This is what I am struggling with. I can get the data from Z, read it and see the destination IP address in the text that is read. But how do I send that to device A, which is still connected via a TCPListener on it's own thread?
I could use static variables and the "lock" mechanism to have the thread look for something to send to the device, but what happens if I add device B & C as well?
I basically need some way of, based on the data sent from Z on a new connection, determining which TCPListener on which thread the data should be sent to the devices.
It's doing my head in so any links you may have or rough logic (doesn't have to be code) would greatly help.
And yes, I've been searching Google for a while, but all the examples I have found are simpler than what I need to do.
Thanks in advance!
you can keep a Dictionary<IPAddress,TCPClient> for this purpose and send the message to the destination IP. Make sure you handle the multiple clients from the single IP gracefully either by droping the previous connection while accepting new one or instead having Dictionary<IPAddress,List<TCPClient>>
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.