CPG_M...OINED(3)

πŸ’… CPG_MCAST_JOINED(3) β€” the corosync bestie page πŸŽ€

ok so this is cpg_mcast_joined, and it lives in the Corosync Cluster Engine Programmer's Manual. it's a section 3 library call, it's iconic, and we're gonna get into it. grab a strawberry drink πŸ“


✨ NAME ✨

cpg_mcast_joined β€” multicasts to all groups joined to a handle


πŸ¦‹ SYNOPSIS πŸ¦‹

#include <sys/uio.h>
#include <corosync/cpg.h>

int cpg_mcast_joined(cpg_handle_t handle, cpg_guarantee_t guarantee, struct iovec *iovec, int iov_len);

🌸 DESCRIPTION 🌸

ok bestie listen. cpg_mcast_joined will multicast a message to all the processes that have been joined with the cpg_join(3) function for the same group name. and the way that messages sent to any of the groups joined to the parameter handle get delivered to all subscribed processes in the system?? it's giving broadcast, no cap.

The argument guarantee requests a delivery guarantee for the message to be sent. The cpg_guarantee_t type is defined by:

typedef enum {
        CPG_TYPE_UNORDERED,     /* not implemented */
        CPG_TYPE_FIFO,          /* same as agreed */
        CPG_TYPE_AGREED,        /* implemented */
        CPG_TYPE_SAFE           /* not implemented */
} cpg_guarantee_t;

The meanings of the cpg_guarantee_t typedef are, one by one, periodt:

CPG_TYPE_UNORDERED Messages are guaranteed to be delivered, but with no particular order. This mode is unimplemented in the CPG library. so like… it exists as a concept, it does not exist as a feature πŸ™ˆ

CPG_TYPE_FIFO Messages are guaranteed to be delivered in first sent first delivery order. In fact, this guarantee is equivalent to the CPG_TYPE_AGREED guarantee. same thing, different name, we love a twin moment πŸ’–

CPG_TYPE_AGREED All processors must agree on the order of delivery. If a message is sent from two or more processes at about the same time, the delivery will occur in the same order to all processes. this is the one that actually works, she's the main character πŸ‘‘

CPG_TYPE_SAFE All processes must agree on the order of delivery. Further all processes must have a copy of the message before any delivery takes place. This mode is unimplemented in the CPG library. literally not implemented, do not come for her πŸ’€

The iovec argument describes the scatter/gather list which is used to transmit a message. This is a iovec described by:

struct iovec
{
        void *iov_base;     /* Pointer to data.  */
        unsigned int iov_len;     /* Length of data.  */
};

The iov_len argument describes the number of entries in the iovec argument. that's it, that's the whole thing 🫢


⭐ RETURN VALUE ⭐

This call returns the CS_OK value if successful, otherwise an error is returned. slay when it works, sigh when it doesn't 😭


πŸ’€ ERRORS πŸ’€

The errors are undocumented. yeah. that's the whole section. not me getting nothing πŸ˜­πŸ™ˆ


🌈 SEE ALSO 🌈

CS_ERR_TRY_AGAIN β€” Resource temporarily unavailable

CS_ERR_INVALID_PARAM β€” Invalid argument

CS_ERR_ACCESS β€” Permission denied

CS_ERR_LIBRARY β€” The connection failed

CS_ERR_INTERRUPT β€” System call interrupted by a signal

CS_ERR_NOT_SUPPORTED β€” The requested protocol/functionality not supported

CS_ERR_MESSAGE_ERROR β€” Incorrect auth message received

CS_ERR_NO_MEMORY β€” Not enough memory to complete the requested task


ok that's the page!! πŸ’– it's from the corosync Man Page, dated 2004-08-31, and yes the header really does render as CPG_M...OINED(3) and honestly?? she's been truncating like that since 2004 and we respect the legacy πŸŽ€βœ¨ go forth and multicast, bestie πŸ¦‹πŸ”₯

πŸ“¦ where this page comes from