C server in linux Voyage (alix3d3 board)

[occam25]

Hi!

I am programming a server in C for an alix3d3 board (500Mhz, 256Mb DDR DRAM) with linux Voyage. The number of clients will be very small (max 5) but the amount of information to send to the client/s could be a lot.

It is the first time I program a server in linux and I am not sure which is the best way to handle the sockets, with processes or threads.

I mean, create a new process with fork() to open a socket that is listening all the time and create another new process for each client connected or do all this with threads instead of processes.

I also have to receive information from the rs232 so I guess I have to create another process(or thread?) to be reading the serial port all the time

so, what would you use in this case, processes or threads?

if the answer is process, what is the best (fastest) way to comunicate between them, pipes?


greetings,

javi

[Rubberman]

Writing robust servers in a distributed environment is not a trivial matter. I know, because I have been doing that, and developing application development frameworks in C and C++, for almost 30 years. There are situations where using threads is very useful, but trust me when I say that to use what I call coarse-grained threading (processes instead of therads) is a LOT easier to get correct and reliable. I would advise to use a message bus or message queues for inter-process communication needs instead of pipes (more flexible). In any case, the main reason why a newbie to this domain such as yourself should use processes instead of threads is that you avoid the entire issue of dealing with locking critical data elements for multi-thread access. You won't be spending the next 6 months trying to find out why some deadlock is happening.

FYI, I was the principal engineer and architect of the transaction processing framework used to write the servers that run most semiconductor, flat-panel display, and disc drive manufacturing plants world-wide. That framework enabled the development of coarse-grained, fault-resiliant, high volume, transaction processing applications that serve hundreds of concurrent users, factory equipment, databases, etc. and handles hundreds of thousands of transactions per hour with only a few servers.

[occam25]

But threads are more efficient and faster, arent they? (remember I have only 500Mhz and 256M of RAM).. I dont have to program pipes or a message bus to comunicate between them and I would only need one thread to read the serial port (with mutex to avoid write and read at the same time -> I have finished thar part and is working fine), another one for the listening socket and one or two more for the connected clients (I said 5 but finally the max number of clients will be 2).
Don't you think that in this case threads could be better than procceses?
Would it be very difficult with only 4 threads?

Apart from the debugging problems I think that threads will fit better in a alix board with only 500Mhz and 256M of RAM..

tell me what you think, your huge experience can help me a lot!

thanks for the advice rubberman,

javi

[Rubberman]

Using threads in this type of situation on a resource-constrained system is not a bad idea. However, you need to clearly identify where conflicts between threads are likely to occur - concurrent access to writable data structures including global and static (both unit and function static) variables are likely. You will need to use some sort of access serialization method to ensure safe access, such as a mutex, semaphore, etc. Also, make sure that you are using the reintrant version of standard C library functions - identified by a _r at the end of the function name, such as strerror_r() instead of strerror().

[occam25]

Hi Rubberman,
I have done a brief and simple flowchart of the program. Can you take a look and tell me what you think?

1. I create a thread to write the log messages from the log messages queue to the log file. So if at any point of the program I want to write a log message, I only have to put it in the queue and forget about it

2. Port one and two are to control a PTZ. In port 1 I will be reading the azimuth and elevation degrees of the PTZ and, through port 2, I will send the orders to move it

3. In the main process I open a socket to listen and accept any conection request. I create a new thread for each client to receive orders and send all the data


all looks simple in the paper! problems will come later.. : P

thanks!

[Rubberman]

Well, it seems simple enough. A couple of points to consider:

1. Who besides the Port 1 thread is going to be accessing (reading - I assume only Port 1 thread will write to them) the PTZ variables. If any other thread, then you need to guard those variables when you go to read or update them. A mutex will work well for that.
2. You don't accomodate disconnections in your client threads. Also, in your main thread you need to keep track of the client threads terminating because of a disconnection.

Other than these 2 points, your workflow seems clean enough. Let us know how it progresses.

[occam25]

yes, the port 2 thread reads PTZ variables that have been updated by port 1 thread. I will use a mutex, as you say, to sincronize them and avoid collisions.

And you are right, I did not think about threads termination. I will work on it and will tell you something.

thankS!