Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarification for eXtended Headers in MetaHeader #204

Merged
merged 2 commits into from
May 17, 2022
+59 −0
Merged

Clarification for eXtended Headers in MetaHeader #204

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
097613c
Clarification for eXtended Headers in MetaHeader
Mar 5, 2022
709f850
Update
EliChin May 13, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
59 changes: 59 additions & 0 deletions object/service.proto
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,6 +19,17 @@ service ObjectService {
// be restored by concatenation of object message payload and all chunks
// keeping the receiving order.
//
// Extended headers can change `Get` behaviour:
// * __NEOFS__NETMAP_EPOCH \
// Will use the requsted version of Network Map for object placement
// calculation.
// * __NEOFS__NETMAP_LOOKUP_DEPTH \
// Will try older versions (starting from `__NEOFS__NETMAP_EPOCH` if specified or
// the latest one otherwise) of Network Map to find an object until the depth
// limit is reached.
//
// Please refer to detailed `XHeader` description.
//
// Statuses:
// - **OK** (0, SECTION_SUCCESS): \
// object has been successfully read;
Expand All @@ -42,6 +53,13 @@ service ObjectService {
// object payload. All messages, except first one, SHOULD be payload chunks.
// Chunk messages SHOULD be sent in the direct order of fragmentation.
//
// Extended headers can change `Put` behaviour:
// * __NEOFS__NETMAP_EPOCH \
Copy link
Contributor

@cthulhu-rider cthulhu-rider Mar 10, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is useful for Put: can't imagine the scenario when somebody wants to store an object in the "past" and storage nodes accepts it.

Same for Delete.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This functionality is required to address cases with some network segments losing full connectivity. Even if it's not used now by our implementation, the protocol itself must support operation in an Epoch specified.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that we can parameterize this value in binary protocol, but I still can't imagine the UX in setting the particular values. Regardless of the implementation, how are storage nodes that are no longer present in the container motivated to serve these kinds of requests?

// Will use the requsted version of Network Map for object placement
// calculation.
//
// Please refer to detailed `XHeader` description.
//
// Statuses:
// - **OK** (0, SECTION_SUCCESS): \
// object has been successfully saved in the container;
Expand All @@ -66,6 +84,13 @@ service ObjectService {
// Delete the object from a container. There is no immediate removal
// guarantee. Object will be marked for removal and deleted eventually.
//
// Extended headers can change `Delete` behaviour:
// * __NEOFS__NETMAP_EPOCH \
// Will use the requsted version of Network Map for object placement
// calculation.
//
// Please refer to detailed `XHeader` description.
//
// Statuses:
// - **OK** (0, SECTION_SUCCESS): \
// object has been successfully marked to be removed from the container;
Expand All @@ -84,6 +109,13 @@ service ObjectService {
// returned. If `main_only` request field is set, the short header with only
// the very minimal information will be returned instead.
//
// Extended headers can change `Head` behaviour:
// * __NEOFS__NETMAP_EPOCH \
// Will use the requsted version of Network Map for object placement
// calculation.
//
// Please refer to detailed `XHeader` description.
//
// Statuses:
// - **OK** (0, SECTION_SUCCESS): \
// object header has been successfully read;
Expand All @@ -104,6 +136,13 @@ service ObjectService {
// Header's filed values. Please see the corresponding NeoFS Technical
// Specification section for more details.
//
// Extended headers can change `Search` behaviour:
// * __NEOFS__NETMAP_EPOCH \
// Will use the requsted version of Network Map for object placement
// calculation.
//
// Please refer to detailed `XHeader` description.
//
// Statuses:
// - **OK** (0, SECTION_SUCCESS): \
// objects have been successfully selected;
Expand All @@ -121,6 +160,16 @@ service ObjectService {
// restored by concatenation of all received payload chunks keeping the receiving
// order.
//
// Extended headers can change `GetRange` behaviour:
// * __NEOFS__NETMAP_EPOCH \
// Will use the requsted version of Network Map for object placement
// calculation.
// * __NEOFS__NETMAP_LOOKUP_DEPTH \
// Will try older versions of Network Map to find an object until the depth
// limit is reached.
//
// Please refer to detailed `XHeader` description.
//
// Statuses:
// - **OK** (0, SECTION_SUCCESS): \
// data range of the object payload has been successfully read;
Expand All @@ -142,6 +191,16 @@ service ObjectService {
// length) tuples. Hashes order in response corresponds to the ranges order in
// the request. Note that hash is calculated for XORed data.
//
// Extended headers can change `GetRangeHash` behaviour:
// * __NEOFS__NETMAP_EPOCH \
// Will use the requsted version of Network Map for object placement
// calculation.
// * __NEOFS__NETMAP_LOOKUP_DEPTH \
// Will try older versions of Network Map to find an object until the depth
// limit is reached.
//
// Please refer to detailed `XHeader` description.
//
// Statuses:
// - **OK** (0, SECTION_SUCCESS): \
// data range of the object payload has been successfully hashed;
Expand Down