Server that proceses several client requests in UDP

Server that proceses several client requests in UDP

Post by Mario de Sousa Dia » Sat, 15 Mar 2003 00:23:53



Hello everyone

Ho can I program a UDP server that processes several UDP client requests at
the same time.

Thank you

 
 
 

Server that proceses several client requests in UDP

Post by Mario de Sousa Dia » Sat, 15 Mar 2003 00:26:30


Hello everyone

Ho can I program a UDP server that processes several UDP client requests at
the same time. I mean... Let us suposse client1 makes a request to the
server... What I want is to implement the ability of the server to receive
client2 request while he is taking care of client1's request...

Thank you

 
 
 

Server that proceses several client requests in UDP

Post by Valentin Nechaye » Sat, 15 Mar 2003 03:15:59


MdSD> Ho can I program a UDP server that processes several UDP client requests at
MdSD> the same time. I mean... Let us suposse client1 makes a request to the
MdSD> server... What I want is to implement the ability of the server to receive
MdSD> client2 request while he is taking care of client1's request...

Please describe typical pattern of request proceeding in your server.
It may one of the following, or any mix of them:
1. CPU-intensive: do some calculations or data processing in memory,
then send the reply.
2. Disk-intensive: read or write something from/to disk.
3. Inter-process communicative: on client's request, send a request
(the same or another) to another server and wait for result.

If pattern is mixed, define what phase (data processing in memory, disk I/O,
network I/O) requests the maximim time.

-netch-

 
 
 

Server that proceses several client requests in UDP

Post by David Schwart » Sat, 15 Mar 2003 04:47:06



Quote:> Ho can I program a UDP server that processes several UDP client requests at
> the same time. I mean... Let us suposse client1 makes a request to the
> server... What I want is to implement the ability of the server to receive
> client2 request while he is taking care of client1's request...

        It completely depends upon a huge number of factors. The biggest thing
we would need to know to give you an idea of a way to proceed that is at
least reasonable is for you to tell us what you mean by "taking care of
client1's request". Is this doing CPU number crunching? Is this waiting
for disk I/O? Is it waiting for network I/O?

        DS

 
 
 

Server that proceses several client requests in UDP

Post by nobod » Sat, 15 Mar 2003 13:48:15




> > Ho can I program a UDP server that processes several UDP client requests
at
> > the same time. I mean... Let us suposse client1 makes a request to the
> > server... What I want is to implement the ability of the server to
receive
> > client2 request while he is taking care of client1's request...

> It completely depends upon a huge number of factors. The biggest thing
> we would need to know to give you an idea of a way to proceed that is at
> least reasonable is for you to tell us what you mean by "taking care of
> client1's request". Is this doing CPU number crunching? Is this waiting
> for disk I/O? Is it waiting for network I/O?

I believe question was how to process requests concurrently, e.g not to wait
with processing 2nd request until 1st finishes, regardless of what kind of
processing is done.
If that's the case, you can either spawn child process for each request with
fork() or write multithreaded daemon. Threads are less expensive but IMHO
trickier for beginner to use properly. You should read some of Richard
Stevens' books (or others, for that matter). Even to use fork() - with all
implications is not that simple as it may seem at first glance.
Quote:

> DS

 
 
 

Server that proceses several client requests in UDP

Post by William Par » Sat, 15 Mar 2003 17:48:50






>> > Ho can I program a UDP server that processes several UDP client
>> > requests at the same time. I mean... Let us suposse client1 makes a
>> > request to the server... What I want is to implement the ability of
>> > the server to receive client2 request while he is taking care of
>> > client1's request...

>> It completely depends upon a huge number of factors. The biggest
>> thing we would need to know to give you an idea of a way to proceed
>> that is at least reasonable is for you to tell us what you mean by
>> "taking care of client1's request". Is this doing CPU number
>> crunching? Is this waiting for disk I/O? Is it waiting for network
>> I/O?

> I believe question was how to process requests concurrently, e.g not
> to wait with processing 2nd request until 1st finishes, regardless of
> what kind of processing is done.

I think so too.  At his (OP) level, my guess is that 'inetd' pretty
solves his problem.

Quote:> If that's the case, you can either
> spawn child process for each request with fork() or write
> multithreaded daemon. Threads are less expensive but IMHO trickier for
> beginner to use properly. You should read some of Richard Stevens'
> books (or others, for that matter). Even to use fork() - with all
> implications is not that simple as it may seem at first glance.

--

Linux solution for data management and processing.
 
 
 

1. : One socket connection, several client requests?

I have a TCP/IP application where a client machine may be
sending several (100 a minute) separate small requests in
the form of 20 bytes to a server across the network.  Each
request requires only one short response, and may wait five
or more seconds for it.

I'm currently using a connection-oriented server.  For each
new request, the client connect()s to the server, the server
fork()s, a new socket descriptor is returned, and the client
and server interact over the new socket descriptor...

It was suggested that due to the volume and frequency of
requests, that the number of connect()s required is
not efficient.  

It was then suggested that we could send several requests
across an already open connection, and only open a new socket
when the number of requests per socket reached a predefined
number, say five.

The client processes would need to keep track of which response
goes with which request using a request id in the request,
which the server would copy and pass back with the response.
The server would still fork a new process for each request,
and each of those processes would be able to write on the
one socket descriptor.

Does this sound reasonable?  The suggestion was made to
reduce the connect()s, and improve response times for clients,
who wouldn't be waiting the extra time that it takes for
connections to be established.

However, I have never heard of this being done before, and
I'm just a bit skeptical.  

If anyone does respond, feel free to refer to any of Richard
Stevens' books.  

--
+---------------+------------------------------------------------+

+               +------------------------------------------------+
+               | Insert something witty here                    |
+---------------+------------------------------------------------+

2. R5 on new (Lombard) PowerBook -- USB input?

3. Dynamic DHCP server & several BOOTP clients interactions on the same LAN

4. Difference between RH 2.2.5-15 and general 2.2.5

5. UDP broadcast server-client example.

6. changing telnet login params

7. UDP client/server app

8. boca research home FAX modem

9. reliable udp on client server model?

10. Looking for example UDP file transfer code (both client and server) in C

11. pppd dial ins and , "LCP: timeout sending Config-Requests"

12. shortest possible reliable-UDP client/server example

13. Basic UDP server client