## multisocketsink

multisocketsink — Send data to multiple sockets

## Signals

void | add | Action
void | add-full | Action
void | client-added | Run Last
void | client-removed | Run Last
void | client-socket-removed | Run Last
GstStructure* | get-stats | Action
void | remove | Action
void | remove-flush | Action

## Types and Values

struct | GstMultiSocketSink
enum | GstRecoverPolicy
enum | GstSyncMethod
enum | GstClientStatus

## Object Hierarchy

        GObject
        ╰── GInitiallyUnowned
            ╰── GstObject
                ╰── GstElement
                    ╰── GstBaseSink
                        ╰── GstMultiHandleSink
                            ╰── GstMultiSocketSink
                                ╰── GstTCPServerSink

## Description

This plugin writes incoming data to a set of file descriptors. The file descriptors can be added to multisocketsink by emitting the “add” signal. For each descriptor added, the “client-added” signal will be called.

A client can also be added with the “add-full” signal that allows for more control over what and how much data a client initially receives.

Clients can be removed from multisocketsink by emitting the “remove” signal. For each descriptor removed, the “client-removed” signal will be called. The “client-removed” signal can also be fired when multisocketsink decides that a client is not active anymore or, depending on the value of the “recover-policy” property, if the client is reading too slowly. In all cases, multisocketsink will never close a file descriptor itself. The user of multisocketsink is responsible for closing all file descriptors. This can for example be done in response to the “client-fd-removed” signal. Note that multisocketsink still has a reference to the file descriptor when the “client-removed” signal is emitted, so that "get-stats" can be performed on the descriptor; it is therefore not safe to close the file descriptor in the “client-removed” signal handler, and you should use the “client-fd-removed” signal to safely close the fd.

Multisocketsink internally keeps a queue of the incoming buffers and uses a separate thread to send the buffers to the clients. This ensures that no client write can block the pipeline and that clients can read with different speeds.

When adding a client to multisocketsink, the “sync-method” property will define which buffer in the queued buffers will be sent first to the client. Clients can be sent the most recent buffer (which might not be decodable by the client if it is not a keyframe), the next keyframe received in multisocketsink (which can take some time depending on the keyframe rate), or the last received keyframe (which will cause a simple burst-on-connect). Multisocketsink will always keep at least one keyframe in its internal buffers when the sync-mode is set to latest-keyframe.

There are additional values for the “sync-method” property to allow finer control over burst-on-connect behaviour. By selecting the 'burst' method a minimum burst size can be chosen, 'burst-keyframe' additionally requires that the burst begin with a keyframe, and 'burst-with-keyframe' attempts to burst beginning with a keyframe, but will prefer a minimum burst size even if it requires not starting with a keyframe.

Multisocketsink can be instructed to keep at least a minimum amount of data expressed in time or byte units in its internal queues with the “time-min” and “bytes-min” properties respectively. These properties are useful if the application adds clients with the “add-full” signal to make sure that a burst connect can actually be honored.

When streaming data, clients are allowed to read at a different rate than the rate at which multisocketsink receives data. If the client is reading too fast, no data will be send to the client until multisocketsink receives more data. If the client, however, reads too slowly, data for that client will be queued up in multisocketsink. Two properties control the amount of data (buffers) that is queued in multisocketsink: “buffers-max” and “buffers-soft-max”. A client that falls behind by “buffers-max” is removed from multisocketsink forcibly.

A client with a lag of at least “buffers-soft-max” enters the recovery procedure which is controlled with the “recover-policy” property. A recover policy of NONE will do nothing, RESYNC_LATEST will send the most recently received buffer as the next buffer for the client, RESYNC_SOFT_LIMIT positions the client to the soft limit in the buffer queue and RESYNC_KEYFRAME positions the client at the most recent keyframe in the buffer queue.

multisocketsink will by default synchronize on the clock before serving the buffers to the clients. This behaviour can be disabled by setting the sync property to FALSE. Multisocketsink will by default not do QoS and will never drop late buffers.

## Synopsis

### Element Information

plugin | tcp
author | Thomas Vander Stichele <thomas at apestaart dot org>, Wim Taymans <wim@fluendo.com>, Sebastian Dröge <sebastian.droege@collabora.co.uk>
class | Sink/Network

### Element Pads

name | sink
direction | sink
presence | always
details | ANY

## Functions

## Types and Values

### struct GstMultiSocketSink

    struct GstMultiSocketSink;

The multisocketsink object structure.

### enum GstRecoverPolicy

Possible values for the recovery procedure to use when a client consumes data too slow and has a backlag of more that soft-limit buffers.

#### Members

GST_RECOVER_POLICY_NONE |  |
GST_RECOVER_POLICY_RESYNC_LATEST |  |
GST_RECOVER_POLICY_RESYNC_SOFT_LIMIT |  |
GST_RECOVER_POLICY_RESYNC_KEYFRAME |  |

### enum GstSyncMethod

This enum defines the selection of the first buffer that is sent to a new client.

#### Members

GST_SYNC_METHOD_LATEST |  |
GST_SYNC_METHOD_NEXT_KEYFRAME |  |
GST_SYNC_METHOD_LATEST_KEYFRAME |  |
GST_SYNC_METHOD_BURST |  |
GST_SYNC_METHOD_BURST_KEYFRAME |  |
GST_SYNC_METHOD_BURST_WITH_KEYFRAME |  |

### enum GstClientStatus

This specifies the reason why a client was removed from multisocketsink and is received in the "client-removed" signal.

#### Members

GST_CLIENT_STATUS_OK |  |
GST_CLIENT_STATUS_CLOSED |  |
GST_CLIENT_STATUS_REMOVED |  |
GST_CLIENT_STATUS_SLOW |  |
GST_CLIENT_STATUS_ERROR |  |
GST_CLIENT_STATUS_DUPLICATE |  |
GST_CLIENT_STATUS_FLUSHING |  |

## Signal Details

### The `“add”` signal

    void
    user_function (GstMultiSocketSink *gstmultisocketsink,
                   GSocket            *socket,
                   gpointer            user_data)

Hand the given open socket to multisocketsink to write to.

#### Parameters

gstmultisocketsink | the multisocketsink element to emit this signal on |
socket | the socket to add to multisocketsink |
user_data | user data set when the signal handler was connected. |

Flags: Action

### The `“add-full”` signal

    void
    user_function (GstMultiSocketSink          *gstmultisocketsink,
                   GSocket                     *socket,
                   GstMultiHandleSinkSyncMethod sync,
                   GstFormat                    format_min,
                   guint64                      value_min,
                   GstFormat                    format_max,
                   guint64                      value_max,
                   gpointer                     user_data)

Hand the given open socket to multisocketsink to write to and specify the burst parameters for the new connection.

#### Parameters

gstmultisocketsink | the multisocketsink element to emit this signal on |
socket | the socket to add to multisocketsink |
sync | the sync method to use |
format_min | the format of `value_min` |
value_min | the minimum amount of data to burst expressed in `format_min` units. |
format_max | the format of `value_max` |
value_max | the maximum amount of data to burst expressed in `format_max` units. |
user_data | user data set when the signal handler was connected. |

Flags: Action

### The `“client-added”` signal

    void
    user_function (GstMultiSocketSink *gstmultisocketsink,
                   GObject            *socket,
                   gpointer            user_data)

The given socket was added to multisocketsink. This signal will be emitted from the streaming thread so application should be prepared for that.

#### Parameters

gstmultisocketsink | the multisocketsink element that emitted this signal |
socket | the socket that was added to multisocketsink |
user_data | user data set when the signal handler was connected. |

Flags: Run Last

### The `“client-removed”` signal

    void
    user_function (GstMultiSocketSink            *gstmultisocketsink,
                   gint                           socket,
                   GstMultiHandleSinkClientStatus status,
                   gpointer                       user_data)

The given socket is about to be removed from multisocketsink. This signal will be emitted from the streaming thread so applications should be prepared for that.

`gstmultisocketsink` still holds a handle to `socket` so it is possible to call the get-stats signal from this callback. For the same reason it is not safe to `close()` and reuse `socket` in this callback.

#### Parameters

gstmultisocketsink | the multisocketsink element that emitted this signal |
socket | the socket that is to be removed from multisocketsink |
status | the reason why the client was removed |
user_data | user data set when the signal handler was connected. |

Flags: Run Last

### The `“client-socket-removed”` signal

    void
    user_function (GstMultiSocketSink *gstmultisocketsink,
                   GSocket            *socket,
                   gpointer            user_data)

The given socket was removed from multisocketsink. This signal will be emitted from the streaming thread so applications should be prepared for that.

In this callback, `gstmultisocketsink` has removed all the information associated with `socket` and it is therefore not possible to call get-stats with `socket` . It is however safe to `close()` and reuse `fd` in the callback.

#### Parameters

gstmultisocketsink | the multisocketsink element that emitted this signal |
socket | the socket that was removed from multisocketsink |
user_data | user data set when the signal handler was connected. |

Flags: Run Last

### The `“get-stats”` signal

    GstStructure*
    user_function (GstMultiSocketSink *gstmultisocketsink,
                   GSocket            *socket,
                   gpointer            user_data)

Get statistics about `socket` . This function returns a GstStructure.

#### Parameters

gstmultisocketsink | the multisocketsink element to emit this signal on |
socket | the socket to get stats of from multisocketsink |
user_data | user data set when the signal handler was connected. |

#### Returns

a GstStructure with the statistics. The structure contains values that represent: total number of bytes sent, time when the client was added, time when the client was disconnected/removed, time the client is/was active, last activity time (in epoch seconds), number of buffers dropped. All times are expressed in nanoseconds (GstClockTime).

Flags: Action

### The `“remove”` signal

    void
    user_function (GstMultiSocketSink *gstmultisocketsink,
                   GSocket            *socket,
                   gpointer            user_data)

Remove the given open socket from multisocketsink.

#### Parameters

gstmultisocketsink | the multisocketsink element to emit this signal on |
socket | the socket to remove from multisocketsink |
user_data | user data set when the signal handler was connected. |

Flags: Action

### The `“remove-flush”` signal

    void
    user_function (GstMultiSocketSink *gstmultisocketsink,
                   GSocket            *socket,
                   gpointer            user_data)

Remove the given open socket from multisocketsink after flushing all the pending data to the socket.

#### Parameters

gstmultisocketsink | the multisocketsink element to emit this signal on |
socket | the socket to remove from multisocketsink |
user_data | user data set when the signal handler was connected. |

Flags: Action

## See Also

tcpserversink