There is another thread going on Socket descriptor passed across fork -- hanging where I posted a forked based client/server pair. Not exactly what the OP was 100% seeking, but enough to get started solving his issues. the basic "forumla" for how to implement the server/client pair is there.

Perl is implemented in C and can pretty much do anything that C can do. In most cases, Perl can do what is needed. In many of the other cases, a C program can be written and interfaced to Perl, perhaps you have heard of XS modules?

There are a number of "well known" models for client/server pairs. The most common is the fork based model because it is the most simple.

Perl is not limited in anyway in terms of grandchildren. You can do it if you want, but I highly advise against it. I guess my first reason would be that there is no need. Second, it is complicated even if there was a need!

A fork based server listens for new client connection requests. A new client shows up and "knocks on the Server's door" to get serviced, the parent delegates the handling of talking to this new person to a subordinate, a child. When the child gets finished, it just "dies", exits(). The parent who started the child gets notified by the Operating System. The resources allocated to that child get reclaimed for re-use.

So parents can have lots of children - hundreds maybe. But when these children finish their jobs, the parent knows about and the resources (memory, socket descriptors, or what ever get freed and re-cycled).

If a child is out there making its own children, then we don't have this simple model (this is a child acting like a parent). If one child makes 3 children from one child from the original parent made, what is anything is the original parent going to know? There can be complicated inefficiencies in returning resources to the main server pool and there is no need for it.

Well anyway that is one reason. Read thru the code that I posted at the top of this reply. And if you like, we'll talk about it some more.

Network programming is complicated stuff:
I recommend the classic, Unix Network Programming by J.Richard Stevens. Unfortunately this pillar of computer science was taken from us at an early age. But his work has been updated with a more recent addition - I figure there are some, relatively minor mistakes in the new version.

If I see a good Perl tut covering the basics, I will report back.