150 likes | 279 Views
Processes. Chapter 3. Servers: General Design Issues. 3.7. Client-to-server binding using a daemon as in DCE Client-to-server binding using a superserver as in UNIX. A Multithreaded Server Using Pthreads. /* Main server loop - accept and handle requests */
E N D
Processes Chapter 3
Servers: General Design Issues 3.7 • Client-to-server binding using a daemon as in DCE • Client-to-server binding using a superserver as in UNIX
A Multithreaded Server Using Pthreads • /* Main server loop - accept and handle requests */ • fprintf( stderr, "Server up and running.\n"); • while (1) { • printf("SERVER: Waiting for contact ...\n"); • if ( (sd2=accept(sd, (struct sockaddr *)&cad, &alen)) < 0) { • fprintf(stderr, "accept failed\n"); • exit (1); } • pthread_create(&tid, NULL, serverthread, (void *) sd2 ); • } • void * serverthread(void * parm) { • int tvisits, tsd = (int) parm; • pthread_mutex_lock(&mut); • tvisits = ++visits; • pthread_mutex_unlock(&mut); • printf(“Server has been visited %d times\n", tvisits); • close(tsd); • pthread_exit(0); • }
Reasons for Migrating Code • Improve system performance by balancing the load • Improve application performance by minimizing communication – move code closer to the data • E.g., move the database query close to the database • Improve application performance by executing multiple copies of the same code • E.g., web searching • Make application more flexible • Dynamically configure a distributed application • A change from the traditional client/server approach • Main disadvantage: lack of security
Reasons for Migrating Code • The principle of dynamically configuring a client to communicate to a server. The client first fetches the necessary software, and then invokes the server.
Models for Code Migration • Weak mobility • Transfer only the code segment • Must always start the program from the initial state • E.g. Java applets • Strong mobility • Transfer the execution segment also • A running process can be stopped, transferred, and restarted • Can also be supported by remote cloning – fork a copy at a remote machine • Sender-initiated • E.g. upload programs to a compute server such as a database • Security is an issue – may have to pre-register clients • Receiver-initiated • Target machine takes initiative, easier to implement
Models for Code Migration • Alternatives for code migration.
Migration and Local Resources • Process to resource bindings • Binding by identifier (e.g., URL) • Binding by value (e.g., standard libraries) • Binding by type (e.g., printer) • Resource to machine binding • Unattached resources (easy to move, small files) • Fastened resources (can be moved, but difficult, such as databases or entire Web sites) • Fixed resources (e.g., fixed hardware)
Migration and Local Resources Resource-to machine binding Process-to-resource binding • GR: Establish a global system wide reference • MV: Move the resource • CP: Copy the value of the resource • RB: Rebind the process to a locally available resource • Actions to be taken with respect to the references to local resources when migrating code to another machine.
Migration in Heterogeneous Systems 3-15 • The principle of maintaining a migration stack to support migration of an execution segment in a heterogeneous environment
Migration in Heterogeneous Systems • Migrating open file handles • Move open file handle, process I/O request at the transferred process, submit data over the network • Transfer I/O request over the network • Migrating pages in memory • Stop process, move all pages in memory, restart process • Stop process for a short period of time, move recently used pages, then move other pages concurrently while the process executes – have to deal with writes to pages that have not been moved yet • Move process, use page miss event to move pages as needed – have to be careful with what disk system the pages are coming from
Overview of Code Migration in D'Agents (1) proc factorial n { if ($n 1) { return 1; } # fac(1) = 1 expr $n * [ factorial [expr $n – 1] ] # fac(n) = n * fac(n – 1) } set number … # tells which factorial to compute set machine … # identify the target machine agent_submit $machine –procs factorial –vars number –script {factorial $number } agent_receive … # receive the results (left unspecified for simplicity) • A simple example of a Tel agent in D'Agents submitting a script to a remote machine (adapted from [gray.r95])
Overview of Code Migration in D'Agents (2) all_users $machines proc all_users machines { set list "" # Create an initially empty list foreach m $machines { # Consider all hosts in the set of given machines agent_jump $m # Jump to each host set users [exec who] # Execute the who command append list $users # Append the results to the list } return $list # Return the complete list when done} set machines … # Initialize the set of machines to jump toset this_machine # Set to the host that starts the agent # Create a migrating agent by submitting the script to this machine, from where# it will jump to all the others in $machines. agent_submit $this_machine –procs all_users -vars machines -script { all_users $machines } agent_receive … #receive the results (left unspecified for simplicity) • An example of a Tel agent in D'Agents migrating to different machines where it executes the UNIX who command (adapted from [gray.r95])
Implementation Issues (1) • The architecture of the D'Agents system.