I try to write a multi-user sequential server in c(I think this is called round robin ). The server's behavior is like a cloud .Users give commands like upload and download,share,un-share.And finally, my question is...How can i process those commands sequentially in a non-blocking way? I mean, if clients A and B want to download a file from the server ,how can I gave them chunks of information in a non blocking, way until they have all the informations needed?could you give me some tutorials or useful documentation please?
To make things non-blocking, you need to use poll() or select() system calls. Using these calls, you only read/write when needed, and hence the read/write calls will not block.
Related
I am working with two tcl files. One is a program that connects to a thermal scanner to get information from it via ethernet. I have integrated the other tcl GUI that can reflash the scanner via ethernet. How do I use the connection from the first one to use the flash utility on the second GUI? At first, the two GUI's were separate but I had to combine them for customers.
-let me know if you need any code, the programs are about 4000 lines long so I didnt want to put them on here.
A single TCP connection can only really be used by one process (at each end) at a time; trying to do otherwise causes confusion. Can you just get each program to talk to the thermal scanner directly? At least theoretically, it ought be able to support multiple simultaneous connections, and that'd be a simple way to work.
But if the device won't work that way, the easiest way to multiplex the communications is to have a single process that actually talks to the device and for the other programs to talk to that multiplexer process (probably via a local socket). The multiplexer doesn't need to have a GUI, but would be told to do things like “flash this file to the scanner” or “stream values out of the scanner”. The details of how to do all this will depend very much on what's actually going on with the communications, but the fcopy command is highly likely to be useful in this, as it can be used to efficiently stream data from one Tcl channel to another.
I'm using MailboxProcessor classes in order to keep separate agents that do their own thing. Normally agents can communicate with one another in the same process, but I want agents to talk to one another when they are on separate processes or even different machines. What kind of mechanism is best for implementing communication between them? Is there some standard solution?
Please note that I'm using Ubuntu instances to run the agents.
I think you're going to have write your own routines to serialize messages, pass them accross the process boundaries and then dispatch them on the other side. This will also require a implementation of a ID system where each mailbox has an ID and processes can send messages to IDs instead of just Mailbox.Send. This is not easy, as local boxes will be able to access local memory, but remote mailboxes will not.
I would look at something like RPyC (http://rpyc.wikidot.com/) as it provides a protocol somewhat like you are looking for.
Basically the answer is 'no' there isn't really a good way to do this.
I am implementing some networking stuff in our project. It has been decided that the communication is very important and we want to do it synchronously. So the client sends something the server acknowledges.
Are there some general best practices for the interaction between the client and the server. For instance if there isn't an answer from the server should the client automatically retry? Should there be a timeout period before it retries? What happens if the acknowledgement fails? At what point do we break the connection and reconnect? Is there some material? I have done searches but nothing is really coming up.
I am looking for best practices in general. I am implementing this in c# (probably with sockets) so if there is anything .Net specific then please let me know too.
First rule of networking - you are sending messages, you are not calling functions.
If you approach networking that way, and don't pretend that you can call functions remotely or have "remote objects", you'll be fine. You never have an actual "thing" on the other side of the network connection - what you have is basically a picture of that thing.
Everything you get from the network is old data. You are never up to date. Because of this, you need to make sure that your messages carry the correct semantics - for instance, you may increment or decrement something by a value, you should not set its value to the current value plus or minus another (as the current value may change by the time your message gets there).
If both the client and the server are written in .NET/C# I would recommend WCF insted of raw sockets as it saves you a from a lot of plumbing code with serialization and deserialization, synchronization of messages etc.
That maybe doesn't really answer your question about best practices though ;-)
The first thing to do is to characterize your specific network in terms of speed, probability of lost messages, nominal and peak traffic, bottlenecks, client and server MTBF, ...
Then and only then you decide what you need for your protocol. In many cases you don't need sophisticated error-handling mechanisms and can reliably implement a service with plain UDP.
In few cases, you will need to build something much more robust in order to maintain a consistent global state among several machines connected through a network that you cannot trust.
The most important thing I found is that messages always should be stateless (read up on REST if this means nothing to you)
For example if your application monitors the number of shipments over a network do not send incremental updates (+x) but always the new total.
In a common think about network programming, I think you should learn about :
1. Socket (of course).
2. Fork and Threading.
3. Locking process (use mutex or semaphore or others).
Hope this help..
I have a server and some clients (about 50) in an intranet. The clients send short (about 40 character) string data to the server and the server answers with a similar string. There are up to (but not permanently) 2-3 requests per second for each client. The server has to serialize the requests to get the response strings.
The system should have as less as possible impact on the network as possible (i.e. the server may run something like a webserver already). It should be as easy to install and administer as possible.
What are the possibilities to achieve this using Delphi (Client: D7, Server up to D2010)?
I use the Synapse library for such a simple server. Its lightning fast, very light, and threads easily. The demo Echo in the main synapse install is a fantastic start for what your trying to do. If you are going to be performing database access inside each request/response thread then I strongly also suggest looking at the connection pool example by Cary Jensen to keep your database connections in check.
TCP, definitely. But I'd like to give a vote for ICS. Never liked Indy ...
What about Indy's TIdTCPServer and TIdTCPClient? They provide command handlers, which makes implementing text-based protocols very straight-forward.
There are a lot of options.
Ultimately, I agree with Smasher and like using sockets. They're quick, easy and portable. If you're dealing with a fairly simple protocol and don't need a full n-tier solution, creating a TCP or HTTP server application is dead simple, very light weight, and easy to make compatible with any client. You can even add SSL support to these stand alone applications without having to configure a web server or interfering with it, if it's already running on the same box.
I use RemObjects SDK for this sort of purpose. It takes care of all the difficult stuff, and I just ask it to connect and make function calls to pass the data.
Ok I know this is pretty broad, but let me narrow it down a bit. I've done a little bit of client-server programming but nothing that would need to handle more than just a couple clients at a time. So I was wondering design-wise what the most mainstream approach to these servers is. And if people could reference either tutorials, books, or ebooks.
Haha ok. didn't really narrow it down. I guess what I'm looking for is a simple but literal example of how the server side program is setup.
The way I see it: client sends command: server receives command and puts into queue, server has either a single dedicated thread or a thread pool that constantly polls this queue, then sends the appropriate response back to the client. Is non-blocking I/O often used?
I suppose just tutorials, time and practice are really what I need.
*EDIT: Thanks for your responses! Here is a little more of what I'm trying to do I suppose.
This is mainly for the purpose of learning so I'd rather steer away from use of frameworks or libraries as much as I can. Take for example this somewhat made up idea:
There is a client program it does some function and constantly streams the output to a server(there can be many of these clients), the server then creates statistics and stores most of the data. And lets say there is an admin client that can log into the server and if any clients are streaming data to the server it in turn would stream that data to each of the admin clients connected.
This is how I envision the server program logic:
The server would have 3 Threads for managing incoming connections(one for each port listening on) then spawning a thread to manage each connection:
1)ClientConnection which would basically just receive output, which we'll just say is text
2)AdminConnection which would be for sending commands between server and admin client
3)AdminDataConnection which would basically be for streaming client output to the admin client
When data comes in from a client to the server the server parses what is relevant and puts that data in a queue lets say adminDataQueue. In turn there is a Thread that watches this queue and every 200ms(or whatever) would check the queue to see if there is data, if there is, then cycle through the AdminDataConnections and send it to each.
Now for the AdminConnection, this would be for any commands or direct requests of data. So you could request for statistics, the server-side would receive the command for statistics then send a command saying incoming statistics, then immediately after that send a statistics object or data.
As for the AdminDataConnection, it is just the output from the clients with maybe a few simple commands intertwined.
Aside from the bandwidth concerns of the logical problem of all the client data being funneled together to each of the admin clients. What sort of problems would arise from this design due to scaling issues(again neglecting bandwidth between clients and server; and admin clients and server.
There are a couple of basic approaches to doing this.
Worker threads or processes. Apache does this in most of its multiprocessing modes. In some versions of this, a thread or process is spawned for each request when the request arrives; in other versions, there's a pool of waiting threads which are assigned work as it arrives (avoiding the fork/thread create overhead when the request arrives).
Asynchronous (non-blocking) I/O and an event loop. This is basically using the UNIX select call (although both FreeBSD and Linux provide more optimized alternatives such as kqueue). lighttpd uses this approach and is able to achieve very high scalability, but any in-server computation blocks all other requests. Concurrent dynamic request handling is passed on to separate processes (via CGI) or waiting processes (via FastCGI or its equivalent).
I don't have any particular references handy to point you to, but if you look at the web sites for open source projects using the different approaches for information on their design wouldn't be a bad start.
In my experience, building a worker thread/process setup is easier when working from the ground up. If you have a good asynchronous framework that integrates fully with your other communications tasks (such as database queries), however, it can be very powerful and frees you from some (but not all) thread locking concerns. If you're working in Python, Twisted is one such framework. I've also been using Lwt for OCaml lately with good success.