Analyzing the concurrency of the server

We will now illustrate that the server that we currently have cannot have multiple clients at the same time. First, execute the Chapter18/example3.py file to run the server again, as follows:

> python3 example3.py
Server up, running, and waiting for call on localhost 8080

Similar to what we did in the previous examples, let's now open another Terminal and use Telnet into the running server:

> telnet localhost 8080
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
<welcome: starting in sum mode>

To create the second client for this server, open another Terminal and type in the same telnet command, as follows:

> telnet localhost 8080
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

Here, we can already see that the server is not handling this second client correctly: it is not sending back the welcome message (<welcome: starting in sum mode>) to this client. If we look at the output of our server, we can also see that it is only registering one client—specifically, the first of the two:

> python3 example3.py
Server up, running, and waiting for call on localhost 8080
Received connection from ('127.0.0.1', 61099)

Next, we will try to enter input from each of the clients. We will see that the server is only successfully handling requests from the first client. Specifically, the following is my output from the first client, with various types of input:

> telnet localhost 8080
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
<welcome: starting in sum mode>
hello
ERROR. Enter only integers separated by commas
1,5
Sum of input numbers: '6'
product
<switching to product mode>
6,7
Product of input numbers: '42'

Now, with the first client still maintaining the connection with the server, switch to the Terminal of the second client and try to enter its own input. You will see that unlike the first client, this client is not receiving any message back from the server:

> telnet localhost 8080
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
hello
1,5
product
6,7

If we look at the server output, we will see that the server is only handling requests from the first client:

> python3 example3.py
Server up, running, and waiting for call on localhost 8080
Received connection from ('127.0.0.1', 61099)
('127.0.0.1', 61099) --> hello
('127.0.0.1', 61099) --> 1,5
('127.0.0.1', 61099) --> 6,7

The only way for the second client to be able to interact with the server is if the first client disconnects from the server—in other words, when we stop the connection between the first client and the server, as follows:

> telnet localhost 8080
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
<welcome: starting in sum mode>
hello
ERROR. Enter only integers separated by commas
1,5
Sum of input numbers: '6'
product
<switching to product mode>
6,7
Product of input numbers: '42'
quit
connection closed
Connection closed by foreign host.

Now, if you switch to the Terminal of the second client, you will see that the client will be flushed with messages from the server that it should have been receiving earlier:

> telnet localhost 8080
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
hello
1,5
product
6,7
<welcome: starting in sum mode>
ERROR. Enter only integers separated by commas
Sum of input numbers: '6'
<switching to product mode>
Product of input numbers: '42'

All of the appropriate replies from the server are now present, but they were sent all at once, and not after each of the input messages. The same surge of information is also illustrated in the output from our server Terminal, as follows:

> python3 example3.py
Server up, running, and waiting for call on localhost 8080
Received connection from ('127.0.0.1', 61099)
('127.0.0.1', 61099) --> hello
('127.0.0.1', 61099) --> 1,5
('127.0.0.1', 61099) --> 6,7
('127.0.0.1', 61099) quit
Received connection from ('127.0.0.1', 61100)
('127.0.0.1', 61100) --> hello
('127.0.0.1', 61100) --> 1,5
('127.0.0.1', 61100) --> 6,7

This output makes it seem as if the server only received the connection from the second client after the first client had quit, when in reality, we created the two clients and had them communicate with the server at the same time. This is because our current server is only able to handle one client at a time, and only after the current client has quit can it move on to the next client that has requested a communication channel. We call this a blocking server.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.138.35.255