It would be helpful to have 4 options for the behavior after opening handshake has been completed:
- leave open
- perform WebSocket closing handshake (as now)
- perform orderely close of TCP connection
- just hard drop the TCP
1 This is useful to test scalability of server wrt maximum open WebSocket connections.
3 This is useful to test scalability for this scenario: a plain old Web site (with multiple HTML pages, not single-page Web app), that has some embedded JS which opens a WS. Think somelike like Google Analytics. When a user click a link or closes the tab, the browser will not perform a WebSocket closing handshake. In fact, it will never do, unless explicitly asked for.
4 This is useful to test how the server behaves when TCP are just hard dropped. DoS resistence, or when there are networking issues.
That could be a command line option like --close keepopen, --close wsclose, --close tcpclose or --close tcpdrop.
It would be helpful to have 4 options for the behavior after opening handshake has been completed:
1 This is useful to test scalability of server wrt maximum open WebSocket connections.
3 This is useful to test scalability for this scenario: a plain old Web site (with multiple HTML pages, not single-page Web app), that has some embedded JS which opens a WS. Think somelike like Google Analytics. When a user click a link or closes the tab, the browser will not perform a WebSocket closing handshake. In fact, it will never do, unless explicitly asked for.
4 This is useful to test how the server behaves when TCP are just hard dropped. DoS resistence, or when there are networking issues.
That could be a command line option like
--close keepopen,--close wsclose,--close tcpcloseor--close tcpdrop.