1 / 14

Processes

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 */

uzuri
Download Presentation

Processes

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Processes Chapter 3

  2. 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

  3. 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); • }

  4. 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

  5. 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.

  6. 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

  7. Models for Code Migration • Alternatives for code migration.

  8. 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)

  9. 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.

  10. Migration in Heterogeneous Systems 3-15 • The principle of maintaining a migration stack to support migration of an execution segment in a heterogeneous environment

  11. 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

  12. 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])

  13. 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])

  14. Implementation Issues (1) • The architecture of the D'Agents system.

More Related