i'm writing a UDP protocol to transfer file, I have a problem into
serverside :
I'd like to fork the server process for any new client.
A code like this (that it's wrong) :

while ((recvfrom(sockfd, buf, sizeof(buf), 0, (struct sockaddr *) &saddr, &s
addr_len))!= 0) {

// new frame
if ( !fork() ) {
// Child process
fork_client(sockfd);
close(sockfd);
exit(0); }
else {
// Parent process . Do nothing
}

}

I would want that any frame incoming from a new client came forked,instead
the old  clients will send frames theirs server.
Do You would have of the suggestions?

--
Flex
Excuse 4 my bad english

[ Post a follow-up to this message ]

Hello Flex,
quote:

> i'm writing a UDP protocol to transfer file, I have a problem into
> serverside :
> I'd like to fork the server process for any new client.
> A code like this (that it's wrong) :


Because UDP is a connectionless protocol, UDP servers are usually
iterative.

In a TCP server, concurrency is natural because you can fork() right
after you returned from listen(), and connect then from the child.
As you noticed, there is no equivalent in UDP. A client doesn't need to
etablish a connection, it just sends the data to the server and basta.

So my first question I guess is: Do you *REALLY* need a concurrent
UDP server? If yes (for instance, the server could be busy in
processing the client's request in such way that it would impact the
performace significantly), then 2 options come to my mind:

1- Design a multi-threaded server, not a forked one. Synchronization
and data exchange between threads is easier than between processes.
But this solution isn't necessarily "trivial".

2- Alternatively, one could imagine a kind of "hand-shake" between
the client and server, and simulates a connexion like TCP does. But
if you're going that way, why not use TCP directly?


Regards,
Loic.
--
Article posté via l'accès Usenet http://www.mes-news.com
Accès par Nnrp ou Web

[ Post a follow-up to this message ]

Il Thu, 15 Jan 2004 15:04:03 +0000, Loic Domaigne ha scritto:
[CUTTING]
quote:

> So my first question I guess is: Do you *REALLY* need a concurrent
> UDP server?

Hi Loic
I need a concurrent server for 2 reasons :

1) Use more clients
2) capture an wrong packet sequence . Example : when the client x send
after a read-request I cannot accept a data packet .
It's more difficult control the correct sequence of all frames if I will
use a single server for all clients
quote:

>If yes (for instance, the server could be busy in
> processing the client's request in such way that it would impact the
> performace significantly), then 2 options come to my mind:
>
> 1- Design a multi-threaded server, not a forked one. Synchronization
> and data exchange between threads is easier than between processes.
> But this solution isn't necessarily "trivial".

Why ? Can you explain me better please
quote:

> 2- Alternatively, one could imagine a kind of "hand-shake" between
> the client and server, and simulates a connexion like TCP does. But
> if you're going that way, why not use TCP directly?


I had to use UDP package because my faculty want UDP :-)

--
Hello Flex

[ Post a follow-up to this message ]

In article <pan.2004.01.15.12.11.26.215948@REfreemail.it>,
Flex <flexNONSPAMM@REfreemail.it> wrote:
quote:

> i'm writing a UDP protocol to transfer file, I have a problem into
> serverside :
> I'd like to fork the server process for any new client.
> A code like this (that it's wrong) :
>
> while ((recvfrom(sockfd, buf, sizeof(buf), 0, (struct sockaddr *) &saddr,
> &saddr_len))!= 0) {
>
>    // new frame
>    if ( !fork() ) {
> 	// Child process
>         fork_client(sockfd);
>         close(sockfd);
>         exit(0); }
>    else {
>         // Parent process . Do nothing
>         }
>
> }
>
> I would want that any frame incoming from a new client came forked,instead
> the old  clients will send frames theirs server.
> Do You would have of the suggestions?


In the child process, call connect() on the socket specifying saddr as
the remote address.  This will cause any packets received from that
remote address/port to the port that sockfd is bound to to be passed to
this socket.

Meanwhile, in the parent process, close sockfd and create a new socket
that's bound to the local port.  This will receive any initial packets
that don't match the remote address/port of any of the connected sockets.

Although UDP is connectionless, the Unix sockets API supports these
pseudo-connections to direct packets from different sources into
different sockets.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA

[ Post a follow-up to this message ]

Il Fri, 16 Jan 2004 05:37:52 +0000, Barry Margolin ha scritto:
quote:

>
> In the child process, call connect() on the socket specifying saddr as
> the remote address.  This will cause any packets received from that
> remote address/port to the port that sockfd is bound to to be passed to
> this socket.
>
> Meanwhile, in the parent process, close sockfd and create a new socket
> that's bound to the local port.  This will receive any initial packets
> that don't match the remote address/port of any of the connected sockets.
>
> Although UDP is connectionless, the Unix sockets API supports these
> pseudo-connections to direct packets from different sources into
> different sockets.


I have modified the code , but it continues  to no work what I must
make?

static int clientfd;         // Client socket
int saddr_len;
int sockfd; 			// network socket file descriptor
struct sockaddr_in saddr;	// address of the server socket descr.
char buf[MAX_STRING];

if ((sockfd=socket(AF_INET,SOCK_DGRAM,0)) < 0)
error("Server: socket not connected ");

saddr.sin_family = AF_INET;
saddr.sin_addr.s_addr= htonl(INADDR_ANY);
saddr.sin_port = htons(PORT);
saddr_len = sizeof(saddr);

if (bind(sockfd, (struct sockaddr *) &saddr, saddr_len) < 0)
error("Server: bind failure ");

listen(sockfd, SOCKET_QUEUE); // Start sockets queues

printf("\nServer started\n");

// Create child process
while (1) {
if (clientfd = accept(sockfd, (struct sockaddr *) &saddr, &saddr_len) < 0 ) 
printf("ERRORE");

if ( !fork() ) {
// Child process Server
fork_client(sockfd);
close(sockfd);
exit(0);
}
else {
// Parent process case don't Fork !!!
}

}


--
Ciao Flex

[ Post a follow-up to this message ]

"Flex" <flexNONSPAMM@REfreemail.it> wrote in message
news:pan.2004.01.15.12.11.26.215948@REfreemail.it...
quote:

> i'm writing a UDP protocol to transfer file, I have a problem into
> serverside :
> I'd like to fork the server process for any new client.
> A code like this (that it's wrong) :
>
> while ((recvfrom(sockfd, buf, sizeof(buf), 0, (struct sockaddr *) &saddr,

&saddr_len))!= 0) {
quote:

>
>    // new frame
>    if ( !fork() ) {
> // Child process
>         fork_client(sockfd);
>         close(sockfd);
>         exit(0); }
>    else {
>         // Parent process . Do nothing
>         }
>
> }
>
> I would want that any frame incoming from a new client came forked,instead
> the old  clients will send frames theirs server.
> Do You would have of the suggestions?


Do you mean that the first packet of each new client will be processed by
new a new process and all the rest of that client will be processed by the
server process ?

I think you can build a multithreaded server that  a new thread is created
for each new client and it will handle all corresponding incoming packets
from that client. Each thread will check , by using its own flag,  to see if
the incoming packet is the first one or not. If it is not the first one,
then call to a common function. It is this common function that processes
all not-the-first-packets.

Vu

[ Post a follow-up to this message ]

Il Fri, 16 Jan 2004 05:58:09 -0600, Vu Pham ha scritto:
quote:

> Do you mean that the first packet of each new client will be processed by
> new a new process and all the rest of that client will be processed by the
> server process ?
>
> I think you can build a multithreaded server that  a new thread is created
> for each new client and it will handle all corresponding incoming packets
> from that client. Each thread will check , by using its own flag,  to see 
if
> the incoming packet is the first one or not. If it is not the first one,
> then call to a common function. It is this common function that processes
> all not-the-first-packets.
>


Thank you , I'm findind to do it
--
Hi Flex

[ Post a follow-up to this message ]

Hi Flex,

enclosed some more thoughts/answer regarding your concurrent
UDP-server. As already discussed by Barry, Vu and myself you have 2
options:

1- You concurrent server is designed in such way that one process (or
thread) will receive the incoming with recvfrom() and that a child (or
thread) processes the request and sends the response back. This is
probably a relatively straightforward solution.

2- A more complicated, but likely more efficiency, is to simulate a
connection. You have two alternatives.

+ As explained by Vu, you could design a multithreaded server.
Basically one thread would receive the incoming packets from the
clients, demultiplexes accordingly to the client's inet address
{ip,port} so that one thread process exactly one client.

+ Or as explained by Garry, you can use the connect trick. See its
explanation. Garry's solution is suited both forked and multithreaded
architecture, whereas Vu's solution is perhaps simpler in a
multithreaded context.

Personally I would go for Garry's solution with a multithreaded server
architecture. But if you aren't familiar with multi-threaded
programming, can be a kind frustrating at the beginning.

If you are a novice in network programming, then go rather for the
solution 1.


Good Luck,
Loic.

[ Post a follow-up to this message ]

"Flex" <flexNONSPAMM@REfreemail.it> wrote in message
news:pan.2004.01.16.13.26.49.768583@REfreemail.it...
quote:

> Il Fri, 16 Jan 2004 05:58:09 -0600, Vu Pham ha scritto:
> 
by[QUOTE] 
the[QUOTE] 
created[QUOTE] 
packets[QUOTE] 
see if[QUOTE] 
processes[QUOTE] 
>
> Thank you , I'm findind to do it


You may already know, but I would like to add : when the threads call to
that common function, some syncrhonization control needs to be implemented.

Vu

[ Post a follow-up to this message ]

"Loic Domaigne" <loic-dev@gmx.net> wrote in message
news:3e0374e6.0401160645.e3de30@posting.google.com...
[...]
quote:

>
>     + As explained by Vu, you could design a multithreaded server.
> Basically one thread would receive the incoming packets from the
> clients, demultiplexes accordingly to the client's inet address
> {ip,port} so that one thread process exactly one client.
>

[...]
My explanation might not be very clear. No, I don't use the demultiplex
method . If there are N clients, then there will be N threads. Each thread
is created whenever there is a new incoming client packet. Then that
corresponding thread will process this first packet they way that the OP
wants, then it will call to a common function ( of the server thread ) to
process all other incoming packets.


Vu

[ Post a follow-up to this message ]