Client/Server - please straighten out the terms

James Robertson jwrober at
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 
> others!):
> 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, 
partitions, etc.

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 mailing list