in reply to Creating a messenger system using sockets and tcp protocol.
My first suggestions are:perlipc and copies of both the Perl Cookbook and Programming Perl.
The following thoughts apply *ONLY* on a closed, isolated network. (Otherwise, you need to be able to specify a host as the server, unless you are wanting to do a completely distributed system, which is beyond what I am considering at the moment.) They are not necessarily the best of ideas, just what came to mind as I read your posting.
I would like to create a client and server chatting system using IO::Socket. The system is for a small closed network of about 30 computers all running Windows XP. They are networked using a switch.
The Perl Cookbook and perlipc provide examples of TCP clients and servers, with the Cookbook including examples of forking, non-forking, and pre-forking servers and bi-directional clients (if memory serves).
The IP's are dynamic, so we can't keep a lock on any IP per computer.
One possible way of handling this might be for a client to knock on the port used by the server on the other hosts on the network, but that would seem like a lot of knocking. Another alternative might be for the server to periodically broadcast UDP packets with its information on the network, and have a client signing on listen for those before trying to connect. (These are just ideas.)
Now i want to do a chatting system like, so the server is always hosted on a certain user's account.
I haven't tested it on a Windows system, but perl has a getlogin() function which might work for what you want there.
Then the client finds the IP address of that user and connects to that.
If the server only runs under the one account, and only one instance of that account is logged on on the network in question, then the previous idea of either 'port-knocking' or a server broadcasting its information would seem valid ideas.
The server should be able to connect at one time 30 separate people using TCP.
A forking or pre-forking server (as mentioned earlier) would seem to fit the bill here.
Then when a client sends a message to a server, it should have a timestamp. Then the server sends the message out to all of the clients in the correct order.
I think I would have the server prepend/append the time stamps, so all messages had a consistent timing. (This avoids the problem of incorrect clocks causing messages to appear out of order.)
The clients are to then display the message. It should be really effective way and really easy to implement.
Because of the range of possible user interfaces you could want to build into such a system later (text/cmd-line, curses, Tk/Tkx, Gtk, etc.),I'll leave this one to you; however, for proof-of-concept, the easiest mechanism at first may be to use a specific line of input to exit, and handle all others as input to be sent.
Hope the ideas help, and good luck with the project. :)