blob: 882c9a8e7a2ba5c2fc0ca477f266c27615580a72 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
|
socket: 0.935
device: 0.862
PID: 0.768
network: 0.668
graphic: 0.646
TCG: 0.626
permissions: 0.566
kernel: 0.534
performance: 0.531
mistranslation: 0.523
architecture: 0.522
assembly: 0.495
debug: 0.448
user-level: 0.440
ppc: 0.434
semantic: 0.433
vnc: 0.401
risc-v: 0.385
arm: 0.371
i386: 0.367
VMM: 0.338
register: 0.315
KVM: 0.267
x86: 0.256
peripherals: 0.234
hypervisor: 0.228
boot: 0.222
files: 0.180
virtual: 0.107
chardev zombie TCP session
Description of problem:
When user terminates TCP session ungracefully (eg: power-cycle or network cable disconnect), the TCP session keeps in established status forever. In this state, new sessions can't access the chardev, since the zombie TCP session keeps exclusive access to chardev.
Steps to reproduce:
1.Establish client session to chardev TCP socket.
2.Power-off the client machine.
3.Establish a new client session
4.Observe that old TCP session is never killed and new session can connect but not interact with chardev.
Additional information:
Suggestions to resolve this and improve the chardev feature:
- enable TCP keep-alive for chardev server.
- allow multiple client sessions concurrently, where chardev output is broadcasted to all client sessions, and chardev input is shared by all clients.
|