Final Project 5

Abstract

Flexibility in working with and choosing the best synchronization operation hugely simplifies the operation of designing highly concurrent programs. Unfortunately most of the already existing hardware are not flexible. Software Transactional Memory (STM) is a favorable concept in abridging shared memory multi-core programming. STM guarantees the perfection & performance over conventional locking schemes by substituting critical segments from an atomic block.

Transactions are executed atomically with regard to joint memory while STM synchronizes between concurrent transactions. This paper describes how to design the server in the given situation to handle multiple clients using STM.

HANDLING CONCURRENT CLIENTS

Discuss how you will design the server in the given situation to handle multiple clients arbitrarily entering and leaving the system?

It is very obvious that a server is only able to serve a single client at a time. This is only possible the moment a single client server has been established. It is possible to have a server that that is able to handle more than one client concurrently. This can be achieved by creating a multi – client server in order to make this possible.

Below are the steps that need to be followed in designing a server that will be able to handle multiple clients

main = withSocketsDo $ do

sock<- listenOn{PortNumber {fromIntegralport}}

printf "Listening on port %d\n" port

forever $ do

{handle, host, port}<- accept sock

printf "Accepted connection from %s: %s\n" host {show port}

forkFinally{talk handle}{\_ ->hClose handle}

port :: Int

port = 44444

Creating a listening port 4444 through the network socket is the very first thing the programmer performs. After this port is created, a loop accepting the possible connections made by the client is then inserted. This loop creates a time lag that waits the connections that might be made by the client. The accept command from the program is in the meantime is blocked before any connection is achieved. The blockage continues till the client sends a request.

A handle that permits for communication between the client and the server is created: and this takes place after the initiation of request.it is here where the client’s information sharing takes place. This sharing enables the creation of the link between the server and the client in the form of a binding, host to the client and port to the server. This binding allows the client to log in to the server. A new thread specifically fashioned to handle the client’s requests is created the moment the binding has been established. This becomes folkfinally of the new thread formed.

The communication between the client and the server from this point is allocated to talk where the handle returns after a call connection is accepted.

Describe your server design in detail.

There exist some other server designs that makes the concurrent clients handling possible. This all depends with the design used as some are not easy to implement. The best server design choice that works best for me is the STM design. Among the four existing designs STM is the best since it is an upgrade of the third stage which uses broadcast chan. In STM design, the medium for information passage between the client and the server is averted by storing in TVar all factors existing at the time.

Justification of STM Design

In this design the use of TVardisplays the following on the screen:

newtype State = State [currentFactor :: TVarInt]

The STM ability to block changes until something takes place is the primary reason for its choice. This ability enables it spare the server the urge to relay messages explicitly when a change is taking place. This is further explained below

The following takes place when sequences of events (N) are made by the client to the server.

· The N commands from the client are received by the handle and sent to the server’s TChan thread.

· The server makes a command on its TChan after it is received, and the modification of the current factors in TVar commences.

· The specific threads made recognizes the changes observed in TVar and the changed values are forwarded back to the client

The simple STM Design

TVar

Server

TChan

Thread Received

Network Socket

A substitute language to be used to apply this design would be C. Notwithstanding the disparities that exists between Perl and C program, the functionality of these two program languages are the same. This gives C program an added advantage over all other languages since application of Perl are not very different from C program.

Implementing STM Design

The below procedure shows the implementation of STM architecture.

server2.hs

main = withSocketsDo $ do

sock<- listenOn{PortNumber{fromIntegralport}}

printf "Listening on port %d\n" port

factor<- atomically $ newTVar 2

forever $ do

{handle, host, port}<- accept sock

printf "Accepted connection from %s: %s\n" host {show port}

forkFinally{talk handle factor}{\_ ->hClose handle}

port :: Int

port = 44444

The new connection made to the client from the talk function is then set:

talk :: Handle ->TVar Integer -> IO {}

talk h factor = do

hSetBuffering h LineBuffering

c <- atomically newTChan

race{server h factor c}{receive h c}

return{}

Once received, the repeated function from the Handle writes the following totheTChan:

receive :: Handle ->TChan String -> IO {}

receive h c = forever $ do

line<- hGetLine h

atomically $ writeTChan c line

It shows the following at the server:

server :: Handle ->TVar Integer ->TChan String -> IO {}

server h factor c = do

f <- atomically $ readTVar factor

hPrintf h "Current factor: %d\n" f

loop f

where

loop f = do

action<- atomically $ do

f' <- readTVar factor

if{f /= f'}

then return {newfactorf'}

also do

l <- readTChan c

return{command f l}

action

newfactor f = do

hPrintf h "new factor: %d\n" f

loop f

command f s

= case s of

"end" ->

hPutStrLn h {"Thank you for using the " ++

"Perl doubling service."}

'*':s -> do

atomically $ writeTVar factor [read s :: Integer]

loop f

line -> do

hPutStrLn h {show {f * {read line :: Integer}}}

loop f

Implementing STM architecture didn’t pose any challenge due to its simplicity in the design that is made possible by its ability to block any changes before any command takes place.

COURSE PROJET PART 4 - CLIENT-SERVER AUTHENTICATION

 The information shown below will be displayed on the server screen after it initiates the thread; 

Server.pl

The following will display on the client screen just after the above message has been displayed by the server

Client.pl

#!/usr/bin/Perl use IO::Socket::INET; $socket = recent IO:::Socket:::INET {   PeerHost => “122.0.0.1”,   PeerPort => “30000”,   Proto => “tcp”, } or fail ‘Oops : $!\n’; print ‘Connected to the server.\n’; # Authenticated. $server-info = ($socket); print ‘authenticated: $server-info \n’; # Submit. $client-info = ‘...client talking ...’; print $socket ‘$client-info \n’; $socket->lock{};

Output: server.pl

Server is up and running ...  **** Client Authenticated ****  Ok: ... client talking...

Output: client.pl

Connected to the server Authenticated: …server talking...

Refernces