Otro lugar donde se pueden utilizar las cookies son las rellamadas. Un servidor puede especificar una rellamada (definida por el usuario) de forma que sepa cuándo se utiliza un contexto por primera vez mediante la función rpc_gss_set_callback(). Cuando se utiliza un contexto por primera vez para el intercambio de datos, después de que se establezca para el programa y la versión especificados, se invocará a la rellamada.
La rutina de rellamada definida por el usuario tiene el formato siguiente:
El segundo y el tercer argumento, deleg y gss_context, son tipos de datos de GSS-API y actualmente no están expuestos, de forma que la función de rellamada puede ignorarlos. (brevemente, deleg es la identidad de cualquier delegado igual, mientras que gss_context es un puntero al contexto de GSS-API, por si el programa deseara realizar operaciones de GSS-API en el contexto, es decir, para probar los criterios de aceptación). El argumento cookie ya se ha comentado.
El argumento lock es un puntero a una estructura rpc_gss_lock_t:
typedef struct { bool_t locked;. rpc_gss_rawcred_t *raw_cred; } rpc_gss_lock_t;Este parámetro permite a un servidor aplicar QOP y un servicio determinados para la sesión. QOP y el servicio se encuentran en la estructura rpc_gss_rawcred_t descrita en Ejemplo 8-5 (un servidor no debería cambiar los valores para el servicio y QOP). Cuando se invoca la rellamada definida por el usuario, se define el campo locked como FALSE. Si el servidor define locked como TRUE, sólo se aceptarán las solicitudes con valores de QOP y de servicio que concuerden con los de la estructura rpc_gss_rawcred_t.
Para obtener más información, véase la página del comando man rpc_gss_set_callback(3N.