1. Home
  2. Embedded Linux
  3. Designing a TCP/IP server for ARM

Designing a TCP/IP server for ARM

Hey everyOne!

I'm using ARM - 9 Series with running linux kernel version 2.4.x. I have setup a server application for accepting TCP/IP requests and it works fine. Now what I want t know is that what should be the generic design for this server? My existing design is something like: SERVER:

1) Creating a socket for incoming. 2) Bind it statically. 3) Waiting for client 4) Get the request from client [ Receive ] 5) Do appropriate actions 6) Send result back to client [ Send ] 7) Close the client

Step 3 to 7 are in wild loop (while(1)) so every time I receive a request I use to create a new connection and close it as soon as I'm done with step 6.

Following is the abstraction of my client. CLIENT: Say there are tow actions performed by client.

1) Start getting data from server. 2) Stop getting data from server.

I'm doing the above in following manner:

1) Request to connect 2) Send Query to server 3) Receive results from server 4) As server always close the connection so I do the same in client too. Yeah closing the connection.

Step 1 to 4 are performed in wild loop too until there is a Stop reading action.

Design constraint: As this server is for embedded system so along the memory constrains I do have to make it human interactive less.

Question: a) How good and efficient it is to accept and close the collection every time? Where as my client is suppose to get the data from server in continuous manner. b) I have observed on Fedora core that some times I couldn't get the required port but frankly havn't observed this behavior in ARM. Let say it happens on ARM too so what to do then? As there will be no human interaction to kill the running process and start it again;-) c) Shall I keep the connection alive unless timeout or close action from client ?

Thanks for your suggestions. kill -9 (int)ali

Reply to
Ali
Loading thread data ...

The answer depends on whether programmer time or CPU cycles are the critical resource. A simple connection-per-request was how the web started and is probably the right choice if this is for a demo or a one-off project. A stream, or continuous connection usually requires a more complex protocol to separate one request from the next. Also, a streamed approach needs code to detect and respond when the other end just goes away. A streamed protocol will use less communications bandwidth and be faster but will require much more effort on your part.

This happens if the TCP stack thinks the port might still be in use. I get this when my server dies unexpectedly and there were still open connections to the server. The way I get around this is to have my server try to bind to the port and if it fails, the server sleeps for 10 seconds and tries again. This is just one of several possible ways around the problem. The best solution is to find and fix the cause of the server dying unexpectedly.

Hope this helps, Bob Smith

Reply to
Bob Smith

Hi Bob!

Thanks for your valuable comments , yeah , i was also thinking to do the same like waiting for some time and then asking for same port;-) I think i'll go on with existing design as it is simple and easy to maintain. But Bob how this design will behave if there are concurrent request (Clients)?

Regards, ali

Reply to
Ali

hi, a possible solution to serve several clients is to listen at a specific port. in case a client connects accepts()-function returns a new socket handle which you can use to start up a new thread. something like this should work ..

for (;;) { new_thread = thread_pool__get_handle_ptr(); if (new_thread != NULL) { if((new_socket = accept(server_socket, (struct sockaddr *)&client, &client_size)) == -1) { perror("accept"); } } pthread_create(new_thread, NULL, new_connection, (void *)new_socket); }

regards andre

Ali wrote:

Reply to
A. Puschmann

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.