前面第五篇(一)中的一个Socket例子其实就是单线程的,即Server端一次只能接受来自一个Client端的连接,为了更好的说明socket单线程和阻塞模式,下面对前面的例子做修改。
1.单线程+阻塞+交互式
前面的例子是单线程阻塞和非交互式的,现在改写为交互式的,即不会执行一次就结束,希望达到的效果是,发送的数据由User输入,然后Server端进行接收。
Server端:与上个例子一样,并没有什么变化
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
Client端:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
演示:
步骤1:Server端运行服务端程序
1 2 |
|
步骤2:Client A端运行客户端程序
1 2 3 4 5 6 7 8 9 10 |
|
步骤3:在Server端中观察现象
1 2 3 4 5 6 7 8 |
|
如果此时有另一个Client B端再连接进来,会有下面的情况:
1 2 3 |
|
这时如果在Client A端断开连接,则服务端也会关闭套接字,Client B端发送的数据仍然无法被Server端接收。
此时服务端即出现阻塞情况,因为服务端还和Client A处于连接状态,无法接收Client B发送的数据,这也说明了此时的Server端是单线程的。
2.单线程+阻塞+交互式的进阶演示
把上面的例子中的代码再做进一步的修改,以使得阻塞模式的现象更加明显。
Server端:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
Client端:与前面例子的代码一样
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
演示:
步骤1:Server端运行服务端程序
1 2 |
|
步骤2:Client A端运行客户端程序
1 2 3 4 5 6 |
|
步骤3:在Server端中观察现象
1 2 3 4 5 |
|
如果此时有另一个Client B端再连接进来,会有下面的情况:
1 2 3 |
|
Server端的状态依然为:
1 2 3 4 5 |
|
这时试图把Client A端断开:
1 2 3 4 5 6 7 8 9 |
|
再看看Server端的情况:
1 2 3 4 5 6 7 8 |
|
再看看Client B端的情况:
1 2 3 4 |
|
以上的现象,再根据Server端的程序代码,就可以非常好理解单线程模式和阻塞的细节情况了,在这里是这样的:Server端接受Client A端的连接后,即把接受连接的线程释放,但此时仍然占用接收和发送数据的线程,所以Client B端虽然可以连接上Server端,但数据是无法成功被Server端接收的;当Client A端断开与Server端的连接后,Server端的接收和发送数据的线程立即被释放,之后就可以正常接收来自Client B端发送的数据了。
单线程,即数据的串行发送,会导致阻塞,上面的两个例子就非常好地演示了这个阻塞的过程,如果要解决这个问题,当然在Server端就需要支持多线程,即数据折并发。