So I am making this tcp program which simply sends and receives information between a client and a server.
My setup works as follows:
1)Server starts listening
2)Client sends "hello" command as well as a username/password
3)Server sends either "correctpass" or "wrongpass"
4)Client starts sending massive amounts of data in 50kb intervals
5)Server receives and stores this data as it comes
My question is: Is there something I should do to make sure that client doesn't send data when the server isn't listening? Forexample, should there be a command sent from server saying that it successfully got the data? I am just wondering this because I can't have the data come not in order.
I am receiving via tcp and I understand that TCP should send all the data to the server, but my problem is that the server might not be reading at the time that it is sent to it.
My other question is: Is TCP a good protocol for sending lots of small data (adding up to alot) through the internet? Is this how dropbox and other sync utilities communicate with their servers?
Edit:
I am currently using C# and networkstream to communicate
Thanks,
Rohit
First think that you need to do it's to read about data communications protocols and standarts thats already invented.
Includes OSI/ISO http://en.wikipedia.org/wiki/OSI_model
That help you to understand levels of tcp and udp, http, rest and etc.
Learn about technologies designed for interaction and communication like WCF.
But dont forget to play with your custom protocol it gives you experiences and representation how data comunications work and why and when use different protocols and technologies.
To work around data transfer collision you can use reqest/answer organization of communication.
But with WCF service you can do data transfer easyly. Without a lot of coding and misatkes.
Tcp is good to send data and be enshured from data coruption.
my problem is that the server might not be reading at the time that it
is sent to it.
The problem you are worrying about doesn't really exist. If the server doesn't have the connection open you will get a 'connection reset'. If the server isn't reading as fast as you are writing your writes will block in blocking mode, or return a retry indication in non-blocking mode.
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 have been recently writing a UDP server for a 2D shooter game I am making in C# and XNA for PC, which will update and send world data, entity data, chat data .etc when required.
A question recently sprinted into mind when I was creating a way for players to change their weapons; what would happen if in the occasion the packets send to the server requesting a weapon change were lost? This question then made me think of another question; how can I make a way for the client and server to acknowledge receiving certain packets or blocks of data?
So, I came up with the following simple looking solution to tackle this problem :
Server sends packet(s) which require acknowledgement.
Client receives the packet(s) and sends an acknowledgement packet.
Server checks whether or not the client acknowledged the data. If the client has not, resend data.
The proposed solution looks pretty good, but what would happen if in the occasion that the acknowledgement packet gets lost or if anything unintended happens to it?
Would a better solution to this problem be to create a server and client which use TCP and UDP; where TCP is used for data that needs to get there and arrive in order / in one peace, and UDP for data that needs to get there fast and can cope with loss or error?
If a TCP/UDP server and client is a better choice, what are the risks and how would I go around to implement that?
Thanks.
You need to be using TCP if you want to ensure packets are delivered. UDP does not guarantee delivery, but TCP has this built into the protocol.
After sending some tcp data with the blocking/non-blocking methods such as:
Socket.Send() or Socket.SendAsync()
How can I know that my data has received an ACK message?
Can .NET know if TCP data has been successfully sent?
The only way to know for sure is to implement some kind of application-level acknowledgement. The TCP level "ACK" packet is not exposed to the application level at all, so you have to use something more than that.
You make the other end respond to it.
Even if TCP has Acked it, if the receiving end terminates (for good or bad reasons) before processing the message and acting on it, you still don't know, so the only way to know is for the other end to tell you.
This information isn't available from .net's class libraries. I had the same kind of considerations when I started working on this port scanner in C#. I have made use of a .NET wrapper for libpcap (after installing the corresponding driver), the SharpPcap (http://sourceforge.net/projects/sharppcap/), in order to get this kind of information. The ACK packets are obtained through SharpPcap's interface (invoking the native libpcap interface's transparently).
My application is NScanner Port Scanner/Sweeper and you can find the code at codeplex, referencing to you my simple usage of the aforementioned library (http://nscanner.codeplex.com/).
I hope I helped.
"I'm trying to focus on how can you know when your data has been accepted by the other-side of the connection."
I think you need to be aware what type of application layer protocol you are going to implement and what impact this has on application performance.
Take HTTP as an example of a "Streaming like" protocol. A server posts a stream of data to a client. There are no more additional application layer "ACKs" and the server doesn't actually care when and how exactly his stream of data arrives. This is very efficent on high latency links.
Now compare this to SMB! Instead of streaming a file, data is partitioned into blocks. Every successfully transferred block of data is acked on the application layer. This gives you more control, however, it effectively kills the protocol on WAN networks (check out "Bandwidth Delay Product").
Taking this into consideration, you can come up with your own design for your custom protocol.
The TCP layer will keep resending the packet until it receives a successful ACK.
Send will block until this happens - SendAsync will not block, and you can continue processing other stuff while the TCP layer handles sending the packet.
I recommend using Pcap.Net.
You can easily sniff packets using this library in C# and then easily check the packet values.
You can also easily build and send packets.
If you are really certain that you need to know the packet level details of your TCP connection, then in addition to creating the TCP socket for sending, you need your application to use the winpcap API to look at the raw traffic as well. You can install a filter to only receive packets relevant to the particular IP,port combination that determines your remote side.
There are a couple of projects out there creating .NET wrappers for libpcap, for example here