asking help for a peer-to-peer socket programming question

[Matt Gessner]

[email]g14619@yahoo.com[/email] (Amy) wrote in message news:<8977bd67.0307160135.3171cebb@posting.google. com>...

> Hi,
>
> I am writing a socket program in C for a simple concurrent chat
> server, (probably) with fork, NO select() or multithread at this
> moment, and here is my question:
>
> how can I get the previously forked children to know necessary info
> about these lately-generated children so they can communicate with
> each other in a peer-to-peer chatting environment? What is the way to
> let elder child process(es) know and talk to these younger child
> process(es)?
>
> any suggestion or opinion is highly appreciated.
>
> Amy

I've been thinking about this for a little bit now. I think you need
to ask/answer some question about what you're trying to do, because if
you don't give careful consideration to some limitations, you're going
to hit a wall.

a) How many concurrent children do you want to support?

If the number is small (a couple hundred), I'd suggest using pipes between
each child and the parent, and each child can send messages to the parent
which the parent will broadcast out it's collection of active pipes.

You could probably also do the same thing with sockets or shared memory.

b) Are there enough resources configured in the kernel to allow for this?

If not, you're going to have to go in and tweak your kernel. If there's not
enough physical resources, you're going to need to add some :) This is only
if you're planning to have a really big number.

You might consider looking at how IRC servers are designed. They do much
the same thing as I understand you're trying to do. This is only if you
are very brave :)

Next: how are you planning on doing this without select()? You don't give
too many details, but as I see it, you're going to have at least 2 active
IPC paths for each child: one to the parent, and one to the client. You're
going to need some way to do this. Are you going to use non-blocking
sockets or something like that?

Good luck.

HTH

[Amy]

[email]mgessner@yahoo.com[/email] (Matt Gessner) wrote in message news:<909a6ea3.0307160528.52708be0@posting.google. com>...

> [email]g14619@yahoo.com[/email] (Amy) wrote in message news:<8977bd67.0307160135.3171cebb@posting.google. com>...

Hi,

Thank you very much to help me out. Please refer to the insertion for
the answers to your questions.

Amy

> > Hi,
> >
> > I am writing a socket program in C for a simple concurrent chat
> > server, (probably) with fork, NO select() or multithread at this
> > moment, and here is my question:
> >
> > how can I get the previously forked children to know necessary info
> > about these lately-generated children so they can communicate with
> > each other in a peer-to-peer chatting environment? What is the way to
> > let elder child process(es) know and talk to these younger child
> > process(es)?
> >
> > any suggestion or opinion is highly appreciated.
> >
> > Amy

>
> I've been thinking about this for a little bit now. I think you need
> to ask/answer some question about what you're trying to do, because if
> you don't give careful consideration to some limitations, you're going
> to hit a wall.
>
> a) How many concurrent children do you want to support?
>
> If the number is small (a couple hundred), I'd suggest using pipes between
> each child and the parent, and each child can send messages to the parent
> which the parent will broadcast out it's collection of active pipes.
>
> You could probably also do the same thing with sockets or shared memory.

Amy's answer: Only ten children I want to support ( it is a really
tiny chat server)

> b) Are there enough resources configured in the kernel to allow for this?
>
> If not, you're going to have to go in and tweak your kernel. If there's not
> enough physical resources, you're going to need to add some :) This is only
> if you're planning to have a really big number.
>
> You might consider looking at how IRC servers are designed. They do much
> the same thing as I understand you're trying to do. This is only if you
> are very brave :)
>
> Next: how are you planning on doing this without select()? You don't give
> too many details, but as I see it, you're going to have at least 2 active
> IPC paths for each child: one to the parent, and one to the client. You're
> going to need some way to do this. Are you going to use non-blocking
> sockets or something like that?

Amy's answer: Yes, it is a non-blocking and concurrent server. I use
fork() to have the child process to handle login client and let parent
listen to the incoming request. Since broadcast chatting messages is
required, so I have to make the old children know the newly incoming
clients' information (socket discriptor)in order to broadcast messages
to them.

> Good luck.
>
> HTH