I'm using c# to design a client-server application. I'm still a beginner, and am learning the ropes of c# and OO. Right now, I wrote on a piece of paper a few ideas. Essentially, I would create a class "client", which contains all the details (sockets, etc). The client class would be created and stored in an array which would be used by the server in a loop. If 100 clients are connected, would the memory used be significant?
I guess the server would loop through every client in the array checking for a "dataSend" flag that would then flag the server to create a NetworkStream object to the client.
Should I create a networkstream object upon connection of the client and close on connection?
If anyone could point me in the direction of writing my own client-server software, it would be appreciated.
Cam, what you've described isn't quite real client/server design, as the two sides are tightly coupled in your scenario, sharing an array of objects. Think about it instead in terms of requests and responses. The client makes a request to the server over the network, and the server returns a response over the network to the client. They share two things: a common network connection and knowledge of the interface that the server exposes.
The Web is a great, familiar instance of this pattern. The client, your browser, composes an HTTP Request and sends it over a network connection to the server. The server interprets the request and sends an HTTP response back to client. Each knows how to interpret the HTTP standard. That is the link between them, nothing else.
I'd suggest starting out with implementing a very simple request/response. For instance, the client sends a request of 'TIME' and the server responds back with the current time, and the request 'DATE' responds back with the current date. By having a simple protocol to implement, you can concentrate on learning the mechanics of .NET's networking classes.
An array of client classes representing each client connected to the server is a good way to handle this. You might also want to have a member class representing the actual socket and network code, its keeps it cleaner.
Pro tip: Check out the source code to some MUDs.
Cam, we need a bit more detail about what you are trying to achieve to give you a really good answer. Generally, I'd suggest you make use of WCF. You simply need to create a service, define an interface for your operations, and then as many clients can consume that interface as you wish. It's pretty easy in practice.
Something like this would be appropriate:
Like you said, a class Named client to hold client socket.
Maintain a table on server with client's ip:port as key, and client object as value. This will help you keep track of connected clients.
Use asynchronous send and receive for clients. So rather then you iterating through clients, every client will receive data, do the job and respond back to the connected client.
Related
I'm trying to create a tool, which would append/edit something inside specific packets, before they get sent to the specific website.
For now I was using Wpe Pro to apply this filter.
Is there something similar in C# to create this tool?
There is not really a general way to do this. There are multiple possibilities you have to consider and see if they fit your situation. For example you can edit a packet that is send using HTTP by using Pcap.NET (as said in the comments) easily. There are dozens of examples out there on the web that will guide you in modifying packets using Pcap, for example this discussion on the official Pcap.NET forums.
However, if the packet is using HTTPS (SSL/TLS) then the payload, which is the actual data being send, will be encrypted and this could be bypassed; if one/multiple precondition(s) of SSL are broken or by using a tool like sslstrip (python). Note that sslstrip will try to force the socket to be send through HTTP even if HTTPS is requested and this is not guaranteed to work.
Personally I will always try to avoid touching the sockets even anything network related. Especially when it involves HTTPS, because as you probably understand by now, this is pretty hard to bypass. I have no idea what program you are attempting to break, but I felt like it would benefit to this answer.
For HTTP, one could easily create a simple program that hooks the Windows Socket API. You should be looking into the send function and possibly even the recv (receive) function. You can modify the payload as you wish or even replace it with another payload, if desired.
Note that data that is send through the winsock.send function is already encrypted (if SSL/TLS is being used) as the application will handle layers 7 (application layer), 6 (presentation layer) and 5 (session layer, this is where SSL gets applied) of the OSI model. Winsock is a bridge between layer 5 and 4.
For HTTPS you can still use hooking, but you must hook the part of the application where it handles the connections and make sure you apply your (modified) payload before it initializes the connection / sets the payload. This may sound hard to do, put it is actually pretty easy to do, if you are willing to learn and have some time.
I'm very interested in how financial data is streamed from server to client. I often here the term 'push-pull' used. I wondered if someone could give me an example (preferably in Java, C# or perhaps Javascript) how this is actually achieved? Whenever I have written amateur hobby projects at home I often end up querying a URL (containing the price) and continuously calling this within a while(true) loop, with a thread.sleep(x), even if the price doesnt change.
Thanks in advance
Don't know what you mean with 'streaming financial data', but the concept of push/pull is not limited to the financial sector :)
Generally speaking, pull strategy means that the client is actively getting data through a pre-defined communication channel (in your case a socket to an existing and known URL) and polling this channel for new information.
In contrast to that you have the push strategy where you are notified of any changes and you supply the communication channel and register it with the connection's partner. E.g. you have a webservice and your connection partner will post information to that webservice whenever he sees fit. See http://en.wikipedia.org/wiki/Observer_pattern for this concept.
Hope this helps a bit.
If client is working over HTTP the push is always initiated by client, i.e. client requests new updates and server sends them. If client is thin client (i.e. application running in browser) the modern way is to use AJAX to retrieve data without refreshing the page. But again the initiative is at client side, but user just does not see it. It is done on scheduled basis using javascript.
The most "real time" approach is using HTTP tunneling technique: client performs HTTP GET to special URL mapped to servlet that does not close the connection. It just holds it open. When it has something to send to client it writes to stream. So, you get server-to-client push, but still initial connection was performed by client.
You were doing pull. Pulling is when the clients request the data from the server and the server acts on that request.
If the server would have send you data upon receiving new data, that would have been push.
So the difference is: push is initiated by the server and pull is initiated by the client.
Financial data is often transmitted with software like TIBCO Rendezvous. A publisher sends the message to a daemon and listeners that subscribed that subject gets the message from the daemon.
Websockets
EventSource
These are the two web-based PUSH techniques.
As for browser support:
Chrome/Safari/Firefox6 support Both of those.
Opera supports EventSource and Websockets but has the latter disabled by default.
Firefox 4 supports websockets but has it disabled by default.
IE<10 supports neither, IE10 might support one if your lucky
There are many pull techniques, including HTTP and ajax.
I need to create a server process which can push high frequency data (1000 updates per second) to around 50 client. I'm thinking the best way you do this is using async sockets with the SocketAsyncEventArgs type.
The client -> server connections will be long running at least several days to indefinite. I plan to have a server process listening and the clients connect and the server starts pushing the data to the clients.
Can someone point me to or show me an example of how to do this? I can't find any example showing a server process pushing an object to a client.
EDIT: This is over a gigibit LAN. Using windows server with 16 cores and 24gb ram
thanks
First, some more requirements from your side is required. You have server with lots of muscle, but it will fail miserably if you don't do what has to be done.
can the client live without some of the data? I mean, does the stream of the data need to reach other side in proper order, without any drops?
how big is 'the data'? few bytes or?
fact: scheduling interval on windows is 10 msec.
fact: no matter WHEN you send, clients will receive it depending on lots of stuff - network config, number of routers in-between, client processor load, and so on. so you need some kind of timestamping here
Depending on all this, you could design a priority queue with one thread servicing it and sending out UDP datagrams for each client. Also, since (4) is in effect, you can 'clump' some of your data together and have 10 updates per second of 100 data.
If you want to achieve something else, then LAN will be required here with lots of quality network equipment.
If you want to use .NET Sockets to create this server-client project, then this is a good outline of what's needed:
Since the server will be transferring data to several clients simultaneously, you'll need to use the asynchronous Socket.Beginxxx methods or the SocketAsyncEventArgs class.
You'll have clients connect to your server. The server will accept those connections and then add the newly connected client to an internal clients list.
You'll have a thread running within the server, that periodically sends notifications to all sockets in the clients list. If any exceptions/errors occurs while sending data to a socket, then that client is removed from the list.
You'll have to make sure that access to the clients list is synchronized since the server is a multithreaded application.
You don't need to worry about buffering your send data since the TCP stack takes care of that. If you do not want to buffer your data at all (i.e. have the socket send data immediately), then set Socket.NoDelay to true.
It doesn't seem like you need any data from your clients, but if you do, you'd have to make sure your server has a Socket.BeginReceive loop if using Socket.BeginXXX pattern or Socket.ReceiveAsync method if using SocketAsyncEventArgs.
Once you have the connection and transmission of data between server and client going, you then need to worry about serialization and deserialization of objects between client and server.
Serialization which occurs on the server is easy, since you can use the BinaryFormatter or other encoders to encode your object and dump the data onto the socket.
Deserialization on the other hand, which occurs on the client, can be pretty complex because an object can span multiple packets and you can have multiple objects in one packet. You essentially need a way to identify the beginning and end of an object within the stream, so that you can pluck out the object data and deserialize it.
One way to do this is to embed your data in a well known protocol, like HTTP, and send it using that format. Unfortunately, this also means you'd have to write a HTTP parser at the client. Not an easy task.
Another way is to leverage an existing encoding scheme like Google's protocol buffers. This approach would require learning how to use the protocol buffers stack.
You can also embed the data in an XML structure and then have a stream-to-XML decoder on your client side. This is probably the easiest approach but the least efficient.
As you can see, this is not an easy project, but you can get started with the Socket.BeginSend examples here and here, and the SocketAsyncEventArgs example here
Other Tips:
You can improve the reliability of your communication by having the client maintain two connections to the server for redundancy purposes. The reason being that TCP connections take a while to establish, so if one fails, you can still receive data from the other one while the client attempts to reconnect the failed connection.
You can look into using TCPClient class for the client implementation, since it's mostly reading a stream from a network connection.
What about rendezvous or 29 west? It would save reinventing the wheel. Dunno about amqp or zeromq they might work fine too....
I have a server process bound to a port that receives network packets at essentially random intervals. When a packet is received it is parsed and an object representing this packet's data is created. I would like to be able to 'push' this data object to any number, 0..n, client processes running on the same machine. The clients will always be on the localhost.
A client process is only interested in data objects created and pushed by the server since it was launched. This is also a one-way only flow of information. Client's do not need to communicate with the server they just need to receive any new data objects from the server.
The server and client processes are both written in C# using the .Net framework.
Given this setup, what method of IPC would you use to get this to work? My current plan is to serialize the data object and write it to a named pipe that clients read from. Is this the way to go? Also worth noting is that speed isn't a critical factor.
I solved this using WCF callbacks. Clients 'subscribe' to the server, the server then iterates over the subscribed callbacks and calls them with the data to be pushed. When a client process is ended it issues an unsubscribe.
There are loads of examples of this on the net that are fairly easy to follow. For anyone interested these links might help.
http://msdn.microsoft.com/en-us/magazine/cc163537.aspx
http://dotnetaddict.dotnetdevelopersjournal.com/wcf_alarmclock.htm
http://idunno.org/archive/2008/05/29/wcf-callbacks-a-beginners-guide.aspx
Is out there any sample of reading http requests using TCP socket collecting data from them (like emulating Http server in some way) so I wanna to keep data like senders IP:PORT, request body and so on.
So has any one seen such thing in OpenSource projects or do you know how to create it? (if so please provide siple code example)
In retrospect, HTTP is not the easiest protocol to parse. If it were designed from scratch today, it would be very different.
First off, use ASP.NET if possible. If you can't use ASP.NET, then take a look at the HttpListener class.