I have created async library that currently is able to exchange single packets between server and client. Now I am trying to design mechanism that will handle packets in "Request-Response" fashion.
To be more precise lets look at this scenario:
Client sends GiveMeFile packet
Server receives it and instantly replies with HereIsYourFile response packet
Client receives this rssponse and saves the file
In step 2. it is important for client to expect a response and this respons must be received in specific time.
I was thinking about some kind of queue for "expected" responses, that would be cleared of every received response, but I am not sure if this is good approach.
Do you have any suggestions how to implement asynchronous Request-Response pattern?
I have implemented a high performance TCP Server using SocketAsyncEventArgs. You can Google around about it but there is a not so old article on it here which still is useful. SocketAsyncEventArgs totally worked for me to design a concurrent TCP Server.
Related
I need to write a C# application that will sit and run as a service on a windows server.
This application will be responsible for sending JSON snippets to connected clients.
Clients will be connecting using an Asynchronous WebRequest and I want to Gzip encode the payloads to reduce the size of the packets being sent down the wire to each connected client. The data being sent to each client will differ so I need to manage all the connections as well.
Once a client is connected, they will remain connected for as long as possible, so the server will be sending heartbeats every x number of seconds.
I have not done programming like this since my days back in uni and wondered what the best way of achieving this was?
Can I use Sockets and standard TCP/IP with the WebRequest connection method?
I went with the HttpListener in the end.
I'm making a program that requires to make multiple connection on my website and keep it open for a few hours! So, let's say I want to make 300-500 connections and keep them up for 5 hours, if I use threads for each connection, how much CPU would it take approximately? Is there any alternative way to do this instead of using threads as it would take a lot of CPU?
Use asynchronous sockets API.
Asynchronous Server Socket Example
http://msdn.microsoft.com/en-us/library/fx6588te.aspx
Asynchronous Client Socket Example
http://msdn.microsoft.com/en-us/library/bew39x2a.aspx
Using an Asynchronous Server Socket
http://msdn.microsoft.com/en-us/library/5w7b7x5f.aspx
WCF is one option. Another is to consider using a network library which gives you the option of using either threads or asynchronous connections, NetworkComms.Net or lidgren.
Disclaimer: I'm a developer for NetworkComms.Net.
HTTP as an application message protocol doesn't keep a flow back-and-forth of messages, but only a single pair is exchanged; a request and a response, and so from an application perspective it is a connectionless protocol. The connection-oriented TCP part is only to garantuee successful delivery of all data in the request or all data in the response.
As such it doesn't make sense to talk about keeping HTTP connections open from the server. The server might do chunked encoding to pretend it can send multiple reply messages, but that won't work empirically.
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.
I know there is some debate as to whether HTTP is strictly connection-oriented or connectionless. AFAIK, HTTP only maintains a connection long enough to transmit the series of immediate requests. Recently, a microsoft certified architect and I were discussing a method to broadcast updates to a "connected" clients.
Imagine a game of checkers. If player1 makes a move, player2 needs to be notified. With HTTP (no TCP/UDP), the only method I am aware of is to poll. The architect disagreed with me.
So, how can you send updates to "connected" clients using solely HTTP?
There are currently 2 solutions for this:
WebSockets provide a true callback, but are not widely adopted
Use a Comet implementation (such as WebSync). This uses polling.
At the HTTP level, you can stream data that the client can pick up on, by not specifying a Content-Length or closing the connection.
Some clients/servers have a "no data" timeout though so sending a periodic keepalive is a good idea.
Replies need to be in another HTTP request though.
An extension to the stream is the client making a connection and the server not sending any data until there is something ready. The client then processes the reply and immediatly connects again for the next chunk.
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