All of these commands require the depot’s IBP password. This should be looked at again in the future and determine if a better method of security is needed. The current implementation sends the password in the clear and their is no ability to revoke a single clients access to these commands.
Queries the IBP depot resource for its stable storage and the used amount, its volatile storage and the used amount, and the duration.
v1.3
| Client Sends | version IBP_STATUS IBP_ST_INQ password timeout \n |
| Server Responds | status nbytes \n
hard_max_mb hard_used_mb soft_max_mb soft_used_mb max_duration \n
|
v1.4
| Client Sends | version IBP_STATUS rid IBP_ST_INQ password timeout \n |
| Server Responds | status nbytes \n
VS:1.4 DT:dm_type RID:rid RT:rtype CT:ct_bytes ST:st_bytes UT:ut_bytes UH:uh_bytes SH:sh_bytes CH:ch_bytes AT:at_bytes AH:ah_bytes DT:max_duration RE \n
|
Changes the amount of hard and soft storage along with the max duration for an allocation. It is not possible to destroy the data already present in an IBP depot, so the changes only take effect if they are equal or bigger than the currently allocated area.
| Client Sends | version IBP_STATUS rid IBP_ST_CHANGE password timeout \n
max_hard max_soft max_duration \n
|
| Server Responds | status \n |
Returns the list of RIDs currently being managed by the depot.
| Client Sends | version IBP_STATUS IBP_ST_RES timeout \n |
| Server Responds | status rid1 rid2 … ridn \n |
blah blah blah