Client/Server - please straighten out the terms
jwrober at linuxfromscratch.org
Thu Feb 3 08:30:20 PST 2005
Matthew Burgess wrote:
> Randy McMurchy wrote:
>> Could you explain it differently, perhaps without joining remote
>> machine and local machine so much?
> OK, here's what I understand (of course I could be just as confused as
> The client provides an iterface to the user. This User Interface is
> used to choose which profiles to run, validate those profiles, then pass
> them to the server.
> The server is a daemon which listens for connections from the client,
> receives profiles down that connection and processes those profiles
> (i.e. converts them into commands to be run, and executes those
> commands). It will also have to pass status information back up to the
> client, so the user interface can display error messages, etc. to the user.
> That's it in its simplest form - additional functionality will certainly
> be added to both the client and server, but I think that's the core
> stuff covered.
Thanks Matt. That is perfect. The biggest thing to note is that the
client(ui) is dumb. It is only there to control the server-daemon. The
server-daemon does all the work. It is responsible for validating a
profile, initiaiting a LFS build or whatever the profile tells it to do
and maintains all statefull information on it's local box.
Let me try with a sample scenario. I will go with full client/server
separation where there are to boxes involved.
BOX1 = Server. This is what you want your shiny new LFS on. Let's say
for sake of this example that it is a desktop under your desk.
BOX2 = Client. Let's say for sake of this example that it is a laptop
on your desk.
Both are connected to a network. On BOX1 you load the LFS LiveCD, boot
up, login as root, run the net-setup script and then start the alfsd
server daemon. You take note of the IP address the net-setup script
got. You ensure that all the pre-reqs are setup on BOX1 like packages,
On BOX2 you open the alfs client. For this example, let's assume you
are doing it from a console session. You open an ALFS Profile into the
client from your laptop's hard disk somewhere. Probably in your home
dir. You then connect to the server BOX1 from the client on BOX2. You
initiate a transfer of the profile from BOX1 to BOX2 and then instruct
the daemon on BOX2 to validate the profile for you. Once you like the
results that the daemon send back to you, you initiate the GO command
and watch while the profile is executed on BOX1. BOX2 is doing nothing,
but sitting back and listening for messages coming to it from BOX1.
BOX1 is doing all the hard work. It is parsing the profile you sent
it. It is downloading package, compiling packages, etc. You can hear
the HDD humming!
I believe that this should clear everything. BOX1 and BOX2 can be the
same piece of equipment. The only difference is that connection is not
TCP/IP based, it is local socket based, but the alfsd server-daemon must
still be started on the box before the client can connect to it.
More information about the alfs-discuss