in reply to Rather complicated OO (and RPC) question...

A hint on getting better luck with answers. People tend to be more likely to answer focussed questions. Broad, general questions are intrinsically hard to aswer because you don't know where to start or what level to pitch it at.

If you want to do RPC invocations in Perl then I would suggest using an Apache/CGI model because that network code is well understood and debugged. Failing that I would suggest starting with POE for the server. (Of course if you are nearly done, a rewrite to either model may not be worthwhile.)

Beyond that, without a specific socket or RPC question the best that anyone can say is that Lincoln Stein has this great book, there are examples in the Cookbook, and some examples in the documention. If there is something you can put your finger on that you don't understand, it might be worthwhile asking that.

As for a poor factoring between clients and servers, my gut feeling says that it makes sense for clients and servers to share code for part of the communication. I would therefore not be bothered that your clients use that even though you nominally thought that those routines belong in your server class.

Hopefully this is helpful. It isn't very concrete I know, but it is very difficult for me to find satisfactory answers to general questions.

  • Comment on Re (tilly) 1: Rather complicated OO (and RPC) question...

Replies are listed 'Best First'.
Re: Re (tilly) 1: Rather complicated OO (and RPC) question...
by Necos (Friar) on Mar 05, 2002 at 09:54 UTC
    I should point out that this server/client setup is not to use any web servers. The reason being that it requires extra resources on the server (to make sure the web server doesn't bog down the machine). Basically, the only thing I really need to do is setup a socket server, sit it on a port, and wait for connections (using an infinite loop and IO::Select). When a socket comes alive and is ready for reading, then I can capture the data, wrap it in an eval(), and write the results back to the socket. This method seems to me like a better way to go, since it won't be as resource intensive (I can easily have it close after an amount of time and re-run it at a scheduled time). The only thing I haven't figured out is how to remember which socket is being read and which socket will be written to after the eval is completed. I think a little more diving into socket programming will help me to overcome that.

    The POE set of modules also seems like a good idea. The only thing I worry about is implementation of my code over the wire using that module (I was reading the docs for the base POE class, and it didn't say anything about OO... I might have to read further into it). In most cases, WWW stuff would be a good idea if this was over the entire net. Since this is a LAN based project, I think a webserver with all of the XML and stuff is quite an overkill (not to mention that WWW stuff is pretty foreign to me in the first place). Simple RPC is all I need.

    Theodore Charles III
    Network Administrator
    Los Angeles Senior High
    4650 W. Olympic Blvd.
    Los Angeles, CA 90019
    323-937-3210 ext. 224
    email->secon_kun@hotmail.com
[reply]
      What kind of machines are you talking about?

      You mentioned Windows. The GUI on Windows continually takes up several times the resources of a webserver. Any Windows machine with enough resources to run Office can function perfectly well as a webserver. Or to put it another way, a P100 with 32 MB of RAM is overkill for running a low-volume webserver, as long as you are using an OS that is not resource heavy. (Erm, you mentioned Windows? Nevermind.)

      I highly doubt that server resources will be a constraint preventing your running a webserver.

      Now your not knowing WWW is a good argument against. But on the other hand the amount you need to learn to write a CGI is less than the amount you need to learn to write a custom client-server application...

[reply]
        My job computers are all WinNT/2000/XP for the desktops and laptops, WinNT 4 for the servers. I don't trust a webserver to run well in NT period (it can barely run an IRC server for crying out loud). Like I said before, I think the custom client/server model will be the best idea for this situation since I can have a VERY light setup (remember, this stuff is running under Windows). The program will be running on multiple servers, as to avoid blocking up the whole time in order to run all the RPC stuff.

        Server specs are something in the order of:
        1 dual p3-700 with 1 gig of ram (no problem for this server whatsoever), 1 p2-400 with 128 megs of ram (this one could have problems if bogged down for too long), 1 p2-233 with 256 megs of ram (this one is quite dead if it gets hit with a lot of requests), and 1 p2-233 with 128 megs of ram (if this one also gets hit with too many requests, it will hurt badly).

        I always have to keep in mind that there are other services running on these servers. Those services also receive priority over everything else. It sucks that running Windows on these servers takes away a lot of system resources. If I could go back, I would probably have gone the Linux route with directory permissions for each student, along with pushing X sessions down to the client. Of course, the students at my job are computing "n00bs," so it may have been more appropriate to use Windows. Nothing wrong with being a "n00b." We all had to start there sometime.

        If anyone is willing to take a look at the RPC code here in the examples zip file (tarball if you're in BSD/Linux) and has any insight into how to restructure the RPC and/or Msg modules to accept OO, please let me know. Maybe I can get there myself, but more than likely not.

        As always tilly, you've given me advise that's helpful (even if it's not the solution for world hunger), and I'm thankful for it. If you should come up with any "Einsteinian insight" (as my E&M professor likes to say), please toss it my way.

        Thanks,

        Theodore Charles III
        Network Administrator
        Los Angeles Senior High
        4650 W. Olympic Blvd.
        Los Angeles, CA 90019
        323-937-3210 ext. 224
        email->secon_kun@hotmail.com
[reply]

In Section Seekers of Perl Wisdom