Designing a TCP/IP server for ARM

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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


Re: Designing a TCP/IP server for ARM
Quoted text here. Click to load it

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.


Quoted text here. Click to load it
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

Re: Designing a TCP/IP server for ARM
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


Re: Designing a TCP/IP server for ARM
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 ..

<code>
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);
}
</code>


regards
andre


Ali wrote:
Quoted text here. Click to load it

Site Timeline