mirrors/pipewire
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/pipewire/pipewire.git synced 2025-11-08 13:30:08 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions
pipewire/src/modules/module-protocol-native/protocol-footer.h

40 lines
1 KiB
C
Raw Normal View History

treewide: use SPDX tags to specify copyright information SPDX tags make the licensing information easy to understand and clear, and they are machine parseable. See https://spdx.dev for more information.
2023-02-08 18:12:00 +01:00
/* PipeWire */
/* SPDX-FileCopyrightText: Copyright © 2018 Wim Taymans */
/* SPDX-License-Identifier: MIT */
protocol-native: extend v3 protocol with message footers Extend version 3 protocol with message footers, which are for passing around global state data that is not addressed to a specific object. The extension is backward compatible with previous v3 clients, and won't e.g. result to error spam in logs. The footer is a single SPA POD, appended after the main message POD. Because both the protocol message and the message POD record their length, it's possible to append trailing data. Earlier clients will ignore any data trailing the message POD. The footer POD contains a sequence [Id opcode, Struct {...}]*, so there is room to extend with new opcodes later as necessary. There are separate marshal/demarshal routines for messages aimed at resources and proxies.
2022-02-20 14:03:41 +02:00
/*
* Protocol footer.
*
* For passing around general state data that is not associated with
* messages sent to objects.
*/
enum {
protocol-native: footer pre_demarshal must come first Message footer should be handled before attempting to find the object the main message is sent to / checking permissions, because it is not aimed at a specific object. E.g. the registry generation updates should be handled regardless of whether the main message is valid or not, because the updates will not be re-sent. Fixes registry generation updates sometimes going missing.
2022-02-26 00:31:33 +02:00
FOOTER_CORE_OPCODE_GENERATION = 0,
FOOTER_CORE_OPCODE_LAST
protocol-native: extend v3 protocol with message footers Extend version 3 protocol with message footers, which are for passing around global state data that is not addressed to a specific object. The extension is backward compatible with previous v3 clients, and won't e.g. result to error spam in logs. The footer is a single SPA POD, appended after the main message POD. Because both the protocol message and the message POD record their length, it's possible to append trailing data. Earlier clients will ignore any data trailing the message POD. The footer POD contains a sequence [Id opcode, Struct {...}]*, so there is room to extend with new opcodes later as necessary. There are separate marshal/demarshal routines for messages aimed at resources and proxies.
2022-02-20 14:03:41 +02:00
};
enum {
protocol-native: footer pre_demarshal must come first Message footer should be handled before attempting to find the object the main message is sent to / checking permissions, because it is not aimed at a specific object. E.g. the registry generation updates should be handled regardless of whether the main message is valid or not, because the updates will not be re-sent. Fixes registry generation updates sometimes going missing.
2022-02-26 00:31:33 +02:00
FOOTER_CLIENT_OPCODE_GENERATION = 0,
FOOTER_CLIENT_OPCODE_LAST
protocol-native: extend v3 protocol with message footers Extend version 3 protocol with message footers, which are for passing around global state data that is not addressed to a specific object. The extension is backward compatible with previous v3 clients, and won't e.g. result to error spam in logs. The footer is a single SPA POD, appended after the main message POD. Because both the protocol message and the message POD record their length, it's possible to append trailing data. Earlier clients will ignore any data trailing the message POD. The footer POD contains a sequence [Id opcode, Struct {...}]*, so there is room to extend with new opcodes later as necessary. There are separate marshal/demarshal routines for messages aimed at resources and proxies.
2022-02-20 14:03:41 +02:00
};
protocol-native: footer pre_demarshal must come first Message footer should be handled before attempting to find the object the main message is sent to / checking permissions, because it is not aimed at a specific object. E.g. the registry generation updates should be handled regardless of whether the main message is valid or not, because the updates will not be re-sent. Fixes registry generation updates sometimes going missing.
2022-02-26 00:31:33 +02:00
struct footer_core_global_state {
impl-core/protocol-native: use generation counter for global registry Some client messages have bare ids (as opposed to proxies/resources), eg. as in pw_registry_bind/destroy. If the client is processing messages late, these may refer to an object that was already removed, and the id may now refers to a differnt objects. I.e. the following race condition needs to be resolved: server client Global 1 (gen. 1) Global 1 Global 1 remove Global 1 (gen. 2) Bind/destroy 1 Where the client would bind/destroy the wrong global, since it did not yet see the messages for the second one. To keep track of which object the client means, the server keeps track of the "generation number" of its global registry, and what generation the client is at. Each global remembers at what generation of registry they were registered. When processing the messages that use bare ids, check the registry generation of the client, to know whether the message refers to a stale global that was already removed. Messages where client sends bare ids to server are: pw_registry_bind, pw_registry_destroy, metadata_set_property In pw_registry_* do the staleness check directly. Also add staleness check in pw_impl_client_check_permissions, so that also the metadata case is handled. The generation numbers are passed around in message footers, but only if they have changed. When the generation number changes on server, we send the updated value to the client in a message footer. When client has received an update value, it will send the value back in the footer of the next message it sends to the server. Based on: Wim Taymans <wtaymans@redhat.com> "impl-core: check serial number"
2021-11-08 12:26:37 +01:00
uint64_t last_recv_generation;
protocol-native: extend v3 protocol with message footers Extend version 3 protocol with message footers, which are for passing around global state data that is not addressed to a specific object. The extension is backward compatible with previous v3 clients, and won't e.g. result to error spam in logs. The footer is a single SPA POD, appended after the main message POD. Because both the protocol message and the message POD record their length, it's possible to append trailing data. Earlier clients will ignore any data trailing the message POD. The footer POD contains a sequence [Id opcode, Struct {...}]*, so there is room to extend with new opcodes later as necessary. There are separate marshal/demarshal routines for messages aimed at resources and proxies.
2022-02-20 14:03:41 +02:00
};
protocol-native: footer pre_demarshal must come first Message footer should be handled before attempting to find the object the main message is sent to / checking permissions, because it is not aimed at a specific object. E.g. the registry generation updates should be handled regardless of whether the main message is valid or not, because the updates will not be re-sent. Fixes registry generation updates sometimes going missing.
2022-02-26 00:31:33 +02:00
struct footer_client_global_state {
protocol-native: extend v3 protocol with message footers Extend version 3 protocol with message footers, which are for passing around global state data that is not addressed to a specific object. The extension is backward compatible with previous v3 clients, and won't e.g. result to error spam in logs. The footer is a single SPA POD, appended after the main message POD. Because both the protocol message and the message POD record their length, it's possible to append trailing data. Earlier clients will ignore any data trailing the message POD. The footer POD contains a sequence [Id opcode, Struct {...}]*, so there is room to extend with new opcodes later as necessary. There are separate marshal/demarshal routines for messages aimed at resources and proxies.
2022-02-20 14:03:41 +02:00
};
struct footer_demarshal {
int (*demarshal)(void *object, struct spa_pod_parser *parser);
};
protocol-native: footer pre_demarshal must come first Message footer should be handled before attempting to find the object the main message is sent to / checking permissions, because it is not aimed at a specific object. E.g. the registry generation updates should be handled regardless of whether the main message is valid or not, because the updates will not be re-sent. Fixes registry generation updates sometimes going missing.
2022-02-26 00:31:33 +02:00
extern const struct footer_demarshal footer_core_demarshal[FOOTER_CORE_OPCODE_LAST];
extern const struct footer_demarshal footer_client_demarshal[FOOTER_CLIENT_OPCODE_LAST];
protocol-native: extend v3 protocol with message footers Extend version 3 protocol with message footers, which are for passing around global state data that is not addressed to a specific object. The extension is backward compatible with previous v3 clients, and won't e.g. result to error spam in logs. The footer is a single SPA POD, appended after the main message POD. Because both the protocol message and the message POD record their length, it's possible to append trailing data. Earlier clients will ignore any data trailing the message POD. The footer POD contains a sequence [Id opcode, Struct {...}]*, so there is room to extend with new opcodes later as necessary. There are separate marshal/demarshal routines for messages aimed at resources and proxies.
2022-02-20 14:03:41 +02:00
protocol-native: footer pre_demarshal must come first Message footer should be handled before attempting to find the object the main message is sent to / checking permissions, because it is not aimed at a specific object. E.g. the registry generation updates should be handled regardless of whether the main message is valid or not, because the updates will not be re-sent. Fixes registry generation updates sometimes going missing.
2022-02-26 00:31:33 +02:00
void marshal_core_footers(struct footer_core_global_state *state, struct pw_core *core,
protocol-native: extend v3 protocol with message footers Extend version 3 protocol with message footers, which are for passing around global state data that is not addressed to a specific object. The extension is backward compatible with previous v3 clients, and won't e.g. result to error spam in logs. The footer is a single SPA POD, appended after the main message POD. Because both the protocol message and the message POD record their length, it's possible to append trailing data. Earlier clients will ignore any data trailing the message POD. The footer POD contains a sequence [Id opcode, Struct {...}]*, so there is room to extend with new opcodes later as necessary. There are separate marshal/demarshal routines for messages aimed at resources and proxies.
2022-02-20 14:03:41 +02:00
struct spa_pod_builder *builder);
protocol-native: footer pre_demarshal must come first Message footer should be handled before attempting to find the object the main message is sent to / checking permissions, because it is not aimed at a specific object. E.g. the registry generation updates should be handled regardless of whether the main message is valid or not, because the updates will not be re-sent. Fixes registry generation updates sometimes going missing.
2022-02-26 00:31:33 +02:00
void marshal_client_footers(struct footer_client_global_state *state, struct pw_impl_client *client,
protocol-native: extend v3 protocol with message footers Extend version 3 protocol with message footers, which are for passing around global state data that is not addressed to a specific object. The extension is backward compatible with previous v3 clients, and won't e.g. result to error spam in logs. The footer is a single SPA POD, appended after the main message POD. Because both the protocol message and the message POD record their length, it's possible to append trailing data. Earlier clients will ignore any data trailing the message POD. The footer POD contains a sequence [Id opcode, Struct {...}]*, so there is room to extend with new opcodes later as necessary. There are separate marshal/demarshal routines for messages aimed at resources and proxies.
2022-02-20 14:03:41 +02:00
struct spa_pod_builder *builder);
Reference in a new issue Copy permalink