Class TlsClientConnection

Whenever the source_property is changed the target_property is updated using the same value. For instance:

  g_object_bind_property (action, "active", widget, "sensitive", 0);

Will result in the "sensitive" property of the widget #GObject instance to be updated with the same value of the "active" property of the action #GObject instance.

If flags contains %G_BINDING_BIDIRECTIONAL then the binding will be mutual: if target_property on target changes then the source_property on source will be updated as well.

The binding will automatically be removed when either the source or the target instances are finalized. To remove the binding without affecting the source and the target you can just call g_object_unref() on the returned #GBinding instance.

Removing the binding by calling g_object_unref() on it must only be done if the binding, source and target are only used from a single thread and it is clear that both source and target outlive the binding. Especially it is not safe to rely on this if the binding, source or target can be finalized from different threads. Keep another reference to the binding and use g_binding_unbind() instead to be on the safe side.

A #GObject can have multiple bindings.

This function is the language bindings friendly version of g_object_bind_property_full(), using #GClosures instead of function pointers.

Once the stream is closed, all other operations will return %G_IO_ERROR_CLOSED. Closing a stream multiple times will not return an error.

Closing a stream will automatically flush any outstanding buffers in the stream.

Streams will be automatically closed when the last reference is dropped, but you might want to call this function to make sure resources are released as early as possible.

Some streams might keep the backing store of the stream (e.g. a file descriptor) open after the stream is closed. See the documentation for the individual stream for details.

On failure the first error that happened will be reported, but the close operation will finish as much as possible. A stream that failed to close will still return %G_IO_ERROR_CLOSED for all operations. Still, it is important to check and report the error to the user, otherwise there might be a loss of data as all data might not be written.

If cancellable is not NULL, then the operation can be cancelled by triggering the cancellable object from another thread. If the operation was cancelled, the error %G_IO_ERROR_CANCELLED will be returned. Cancelling a close will still leave the stream closed, but some streams can use a faster close that doesn't block to e.g. check errors.

The default implementation of this method just calls close on the individual input/output streams.

For behaviour details see g_io_stream_close().

The asynchronous methods have a default fallback that uses threads to implement asynchronicity, so they are optional for inheriting classes. However, if you override one you must override all.

This is necessary for accessors that modify multiple properties to prevent premature notification while the object is still being modified.

This call retrieves TLS channel binding data as specified in RFC 5056, RFC 5929, and related RFCs. The binding data is returned in data. The data is resized by the callee using #GByteArray buffer management and will be freed when the data is destroyed by g_byte_array_unref(). If data is %NULL, it will only check whether TLS backend is able to fetch the data (e.g. whether type is supported by the TLS backend). It does not guarantee that the data will be available though. That could happen if TLS connection does not support type or the binding data is not available yet due to additional negotiation or input required.

If the peer did not use the ALPN extension, or did not advertise a protocol that matched one of conn's protocols, or the TLS backend does not support ALPN, then this will be %NULL. See g_tls_connection_set_advertised_protocols().

See #GTlsConnection:peer-certificate-errors for more information.

The value can be:

• an empty #GValue initialized by %G_VALUE_INIT, which will be automatically initialized with the expected type of the property (since GLib 2.60)
• a #GValue initialized with the expected type of the property
• a #GValue initialized with a type to which the expected type of the property can be transformed

In general, a copy is made of the property contents and the caller is responsible for freeing the memory by calling g_value_unset().

Note that g_object_get_property() is really intended for language bindings, g_object_get() is much more convenient for C programming.

On the client side, it is never necessary to call this method; although the connection needs to perform a handshake after connecting (or after sending a "STARTTLS"-type command), #GTlsConnection will handle this for you automatically when you try to send or receive data on the connection. You can call g_tls_connection_handshake() manually if you want to know whether the initial handshake succeeded or failed (as opposed to just immediately trying to use conn to read or write, in which case, if it fails, it may not be possible to tell if it failed before or after completing the handshake), but beware that servers may reject client authentication after the handshake has completed, so a successful handshake does not indicate the connection will be usable.

Likewise, on the server side, although a handshake is necessary at the beginning of the communication, you do not need to call this function explicitly unless you want clearer error reporting.

Previously, calling g_tls_connection_handshake() after the initial handshake would trigger a rehandshake; however, this usage was deprecated in GLib 2.60 because rehandshaking was removed from the TLS protocol in TLS 1.3. Since GLib 2.64, calling this function after the initial handshake will no longer do anything.

When using a #GTlsConnection created by #GSocketClient, the #GSocketClient performs the initial handshake, so calling this function manually is not recommended.

#GTlsConnection::accept_certificate may be emitted during the handshake.

When possible, eg. when signaling a property change from within the class that registered the property, you should use g_object_notify_by_pspec() instead.

Note that emission of the notify signal may be blocked with g_object_freeze_notify(). In this case, the signal emissions are queued and will be emitted (in reverse order) when g_object_thaw_notify() is called.

This function omits the property name lookup, hence it is faster than g_object_notify().

One way to avoid using g_object_notify() from within the class that registered the properties, and using g_object_notify_by_pspec() instead, is to store the GParamSpec used with g_object_class_install_property() inside a static array, e.g.:

  enum
  {
    PROP_0,
    PROP_FOO,
    PROP_LAST
  };

  static GParamSpec *properties[PROP_LAST];

  static void
  my_object_class_init (MyObjectClass *klass)
  {
    properties[PROP_FOO] = g_param_spec_int ("foo", "Foo", "The foo",
                                             0, 100,
                                             50,
                                             G_PARAM_READWRITE);
    g_object_class_install_property (gobject_class,
                                     PROP_FOO,
                                     properties[PROP_FOO]);
  }

and then notify a change on the "foo" property with:

  g_object_notify_by_pspec (self, properties[PROP_FOO]);

Since GLib 2.56, if GLIB_VERSION_MAX_ALLOWED is 2.56 or greater, the type of object will be propagated to the return type (using the GCC typeof() extension), so any casting the caller needs to do on the return type must be explicit.

In other words, if the object is floating, then this call "assumes ownership" of the floating reference, converting it to a normal reference by clearing the floating flag while leaving the reference count unchanged. If the object is not floating, then this call adds a new normal reference increasing the reference count by one.

Since GLib 2.56, the type of object will be propagated to the return type under the same conditions as for g_object_ref().

This function should only be called from object system implementations.

See IANA TLS ALPN Protocol IDs for a list of registered protocol IDs.

For a #GTlsClientConnection, this is optional. If a handshake fails with %G_TLS_ERROR_CERTIFICATE_REQUIRED, that means that the server requires a certificate, and if you try connecting again, you should call this method first. You can call g_tls_client_connection_get_accepted_cas() on the failed connection to get a list of Certificate Authorities that the server will accept certificates from.

(It is also possible that a server will allow the connection with or without a certificate; in that case, if you don't provide a certificate, you can tell that the server requested one by the fact that g_tls_client_connection_get_accepted_cas() will return non-%NULL.)

If the object already had an association with that name, the old association will be destroyed.

Internally, the key is converted to a #GQuark using g_quark_from_string(). This means a copy of key is kept permanently (even after object has been finalized) — so it is recommended to only use a small, bounded set of values for key in your program, to avoid the #GQuark storage growing unbounded.

There are nonintuitive security implications when using a non-default database. See #GDtlsConnection:database for details.

The interaction argument will normally be a derived subclass of #GTlsInteraction. %NULL can also be provided if no user interaction should occur for this connection.

In some protocols, the application will know whether or not the connection was closed cleanly based on application-level data (because the application-level data includes a length field, or is somehow self-delimiting); in this case, the close notify is redundant and sometimes omitted. (TLS 1.1 explicitly allows this; in TLS 1.0 it is technically an error, but often done anyway.) You can use g_tls_connection_set_require_close_notify() to tell conn to allow an "unannounced" connection close, in which case the close will show up as a 0-length read, as in a non-TLS #GSocketConnection, and it is up to the application to check that the data has been fully received.

Note that this only affects the behavior when the peer closes the connection; when the application calls g_io_stream_close() itself on conn, this will send a close notification regardless of the setting of this property. If you explicitly want to do an unclean close, you can close conn's #GTlsConnection:base-io-stream rather than closing conn itself, but note that this may only be done when no other operations are pending on conn or the base I/O stream.

When the operation is finished callback will be called. You can then call g_io_stream_splice_finish() to get the result of the operation.

void
object_add_to_user_list (GObject     *object,
                         const gchar *new_string)
{
  // the quark, naming the object data
  GQuark quark_string_list = g_quark_from_static_string ("my-string-list");
  // retrieve the old string list
  GList *list = g_object_steal_qdata (object, quark_string_list);

  // prepend new string
  list = g_list_prepend (list, g_strdup (new_string));
  // this changed 'list', so we need to set it again
  g_object_set_qdata_full (object, quark_string_list, list, free_string_list);
}
static void
free_string_list (gpointer data)
{
  GList *node, *list = data;

  for (node = list; node; node = node->next)
    g_free (node->data);
  g_list_free (list);
}

Using g_object_get_qdata() in the above example, instead of g_object_steal_qdata() would have left the destroy function set, and thus the partial string list would have been freed upon g_object_set_qdata_full().

Duplicate notifications for each property are squashed so that at most one #GObject::notify signal is emitted for each property, in the reverse order in which they have been queued.

It is an error to call this function when the freeze count is zero.

If the pointer to the #GObject may be reused in future (for example, if it is an instance variable of another object), it is recommended to clear the pointer to %NULL rather than retain a dangling pointer to a potentially invalid #GObject instance. Use g_clear_object() for this.

For behaviour details see g_io_stream_close().

The asynchronous methods have a default fallback that uses threads to implement asynchronicity, so they are optional for inheriting classes. However, if you override one you must override all.

If the peer did not use the ALPN extension, or did not advertise a protocol that matched one of conn's protocols, or the TLS backend does not support ALPN, then this will be %NULL. See g_tls_connection_set_advertised_protocols().

On the client side, it is never necessary to call this method; although the connection needs to perform a handshake after connecting (or after sending a "STARTTLS"-type command), #GTlsConnection will handle this for you automatically when you try to send or receive data on the connection. You can call g_tls_connection_handshake() manually if you want to know whether the initial handshake succeeded or failed (as opposed to just immediately trying to use conn to read or write, in which case, if it fails, it may not be possible to tell if it failed before or after completing the handshake), but beware that servers may reject client authentication after the handshake has completed, so a successful handshake does not indicate the connection will be usable.

Likewise, on the server side, although a handshake is necessary at the beginning of the communication, you do not need to call this function explicitly unless you want clearer error reporting.

Previously, calling g_tls_connection_handshake() after the initial handshake would trigger a rehandshake; however, this usage was deprecated in GLib 2.60 because rehandshaking was removed from the TLS protocol in TLS 1.3. Since GLib 2.64, calling this function after the initial handshake will no longer do anything.

When using a #GTlsConnection created by #GSocketClient, the #GSocketClient performs the initial handshake, so calling this function manually is not recommended.

#GTlsConnection::accept_certificate may be emitted during the handshake.

When possible, eg. when signaling a property change from within the class that registered the property, you should use g_object_notify_by_pspec() instead.

Note that emission of the notify signal may be blocked with g_object_freeze_notify(). In this case, the signal emissions are queued and will be emitted (in reverse order) when g_object_thaw_notify() is called.