Prev: Prank script question
Next: NYC LOCAL: Friday 2 April 2010 Student and Startup Hackathon NYC
From: freesoft12 on 1 Apr 2010 10:03
Hi,

I have server and client programs that are compiled as separate
executables.

Their respective behaviors are as follows:

server:

1. Launches the 'client' using fork/execve.
2. Waits for the 'client' to send a stream of information and stores
it inside its data structures.

client:

1. The client has more complex operation.During its course of
operation, it launches other processes that generate information that
must be sent back to the server.
2. Hence the server might get more than one set of information from
the client's child processes.
3. I don't want the client child processes to write to disk as the
client can run for a long time and can generate tons of information.
My idea is for all the information to go to the server and it compacts
the information as much as possible before writing it to disk,
periodically.

Do you have any suggestions on what kind of interprocess communication
should I use to manage this multiple client processes and single
server process communication?


Regards
John
From: Ted Nolan <tednolan> on 1 Apr 2010 13:11
In article <777b6ded-a0ac-4900-a33b-1760707f2483(a)g10g2000yqh.googlegroups.com>,
freesoft12(a)gmail.com <freesoft12(a)gmail.com> wrote:
>Hi,
>
>I have server and client programs that are compiled as separate
>executables.
>
>Their respective behaviors are as follows:
>
>server:
>
>1. Launches the 'client' using fork/execve.
>2. Waits for the 'client' to send a stream of information and stores
>it inside its data structures.
>
>client:
>
>1. The client has more complex operation.During its course of
>operation, it launches other processes that generate information that
>must be sent back to the server.
>2. Hence the server might get more than one set of information from
>the client's child processes.
>3. I don't want the client child processes to write to disk as the
>client can run for a long time and can generate tons of information.
>My idea is for all the information to go to the server and it compacts
>the information as much as possible before writing it to disk,
>periodically.
>
>Do you have any suggestions on what kind of interprocess communication
>should I use to manage this multiple client processes and single
>server process communication?
>
>
>Regards
>John

Have the server open a server TCP socket. When each client is ready, it
can connect to it, and the server can "accept". Then the clients can
write the sockets and the server can read them.

Ted
--
------
columbiaclosings.com
What's not in Columbia anymore..
From: Jasen Betts on 5 Apr 2010 06:04
On 2010-04-01, freesoft12(a)gmail.com <freesoft12(a)gmail.com> wrote:
> Hi,
>
> I have server and client programs that are compiled as separate
> executables.
>
> Their respective behaviors are as follows:
>
> server:
>
> 1. Launches the 'client' using fork/execve.
> 2. Waits for the 'client' to send a stream of information and stores
> it inside its data structures.
>
> client:
>
> 1. The client has more complex operation.During its course of
> operation, it launches other processes that generate information that
> must be sent back to the server.
> 2. Hence the server might get more than one set of information from
> the client's child processes.
> 3. I don't want the client child processes to write to disk as the
> client can run for a long time and can generate tons of information.
> My idea is for all the information to go to the server and it compacts
> the information as much as possible before writing it to disk,
> periodically.
>
> Do you have any suggestions on what kind of interprocess communication
> should I use to manage this multiple client processes and single
> server process communication?

From your description pipes (made using pipe(2)) or anonymous sockets (
socketpair(2)) seem ideal.

the server will use pselect(2) or poll(2) (etc...) to wait for inbpound data

you may want to read up on non-blocking I/O

--- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---
From: Rui Maciel on 5 Apr 2010 08:08
freesoft12(a)gmail.com wrote:

<snip/>
> Do you have any suggestions on what kind of interprocess communication
> should I use to manage this multiple client processes and single
> server process communication?

It may not be of much help but you will certainly get better informed answers in a newsgroup
dedicated to multi-threading programming or parallel computing, such as
comp.programming.threads


Rui Maciel
From: The Natural Philosopher on 5 Apr 2010 08:47
Rui Maciel wrote:
> freesoft12(a)gmail.com wrote:
>
> <snip/>
>> Do you have any suggestions on what kind of interprocess communication
>> should I use to manage this multiple client processes and single
>> server process communication?
>
> It may not be of much help but you will certainly get better informed answers in a newsgroup
> dedicated to multi-threading programming or parallel computing, such as
> comp.programming.threads
>

Or alternatively plagiarise from some of the sources.

For example, have a look at a basic daemon like TFTPD.

And the tftp client processes.


>
> Rui Maciel
 |  Next  |  Last
Pages: 1 2
Prev: Prank script question
Next: NYC LOCAL: Friday 2 April 2010 Student and Startup Hackathon NYC