restructure results

1 files changed, 42 insertions, 0 deletions

diff --git a/results/classifier/zero-shot/118/socket/1949 b/results/classifier/zero-shot/118/socket/1949
new file mode 100644
index 000000000..882c9a8e7
--- /dev/null
+++ b/results/classifier/zero-shot/118/socket/1949
@@ -0,0 +1,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.