shaba/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-25 01:34:11 +03:00
Code Releases Activity
aa0dfb91d5
libvirt/tests/virnetdaemondata/input-data-no-keepalive-required.json

125 lines
2.6 KiB
JSON
Raw Normal View History

rpc: Remove keepalive_required option Since its introduction in 2011 (particularly in commit f4324e329275), the option doesn't work. It just effectively disables all incoming connections. That's because the client private data that contain the 'keepalive_supported' boolean, are initialized to zeroes so the bool is false and the only other place where the bool is used is when checking whether the client supports keepalive. Thus, according to the server, no client supports keepalive. Removing this instead of fixing it is better because a) apparently nobody ever tried it since 2011 (4 years without one month) and b) we cannot know whether the client supports keepalive until we get a ping or pong keepalive packet. And that won't happen until after we dispatched the ConnectOpen call. Another two reasons would be c) the keepalive_required was tracked on the server level, but keepalive_supported was in private data of the client as well as the check that was made in the remote layer, thus making all other instances of virNetServer miss this feature unless they all implemented it for themselves and d) we can always add it back in case there is a request and a use-case for it. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-07-20 15:51:24 +03:00
{
"servers": [
test: Replace tabs with spaces in virnetdaemondata json files JSON data that are used to initialize tests in virnetdaemontest should be in a consistent format, i.e. not using tabs for indentation, those should be replaced by spaces.
2015-08-06 16:33:58 +03:00
{
"min_workers": 10,
"max_workers": 50,
"priority_workers": 5,
"max_clients": 100,
"keepaliveInterval": 120,
"keepaliveCount": 5,
"services": [
{
"auth": 0,
"readonly": true,
"nrequests_client_max": 2,
"socks": [
{
"fd": 100,
"errfd": -1,
"pid": 0,
"isClient": false
}
]
},
{
"auth": 2,
"readonly": false,
"nrequests_client_max": 5,
"socks": [
{
"fd": 101,
"errfd": -1,
"pid": 0,
"isClient": false
}
]
}
],
"clients": [
{
"auth": 1,
"readonly": true,
"nrequests_max": 15,
"sock": {
"fd": 102,
"errfd": -1,
"pid": -1,
"isClient": true
}
},
{
"auth": 2,
"readonly": true,
"nrequests_max": 66,
"sock": {
"fd": 103,
"errfd": -1,
"pid": -1,
"isClient": true
}
}
]
},
{
"min_workers": 2,
"max_workers": 50,
"priority_workers": 5,
"max_clients": 100,
"keepaliveInterval": 120,
"keepaliveCount": 5,
"services": [
{
"auth": 0,
"readonly": true,
"nrequests_client_max": 2,
"socks": [
{
"fd": 100,
"errfd": -1,
"pid": 0,
"isClient": false
}
]
},
{
"auth": 2,
"readonly": false,
"nrequests_client_max": 5,
"socks": [
{
"fd": 101,
"errfd": -1,
"pid": 0,
"isClient": false
}
]
}
],
"clients": [
{
"auth": 1,
"readonly": true,
"nrequests_max": 15,
"sock": {
"fd": 102,
"errfd": -1,
"pid": -1,
"isClient": true
}
},
{
"auth": 2,
"readonly": true,
"nrequests_max": 66,
"sock": {
"fd": 103,
"errfd": -1,
"pid": -1,
"isClient": true
}
}
]
}
rpc: Remove keepalive_required option Since its introduction in 2011 (particularly in commit f4324e329275), the option doesn't work. It just effectively disables all incoming connections. That's because the client private data that contain the 'keepalive_supported' boolean, are initialized to zeroes so the bool is false and the only other place where the bool is used is when checking whether the client supports keepalive. Thus, according to the server, no client supports keepalive. Removing this instead of fixing it is better because a) apparently nobody ever tried it since 2011 (4 years without one month) and b) we cannot know whether the client supports keepalive until we get a ping or pong keepalive packet. And that won't happen until after we dispatched the ConnectOpen call. Another two reasons would be c) the keepalive_required was tracked on the server level, but keepalive_supported was in private data of the client as well as the check that was made in the remote layer, thus making all other instances of virNetServer miss this feature unless they all implemented it for themselves and d) we can always add it back in case there is a request and a use-case for it. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-07-20 15:51:24 +03:00
]
}
Copy Permalink