Nachdem im ersten Teil das grundlegende Quelltextskelett erstellt wurde, geht es heute darum, bis zum Senden und Empfang der ersten Nachrichten zu kommen. Zur Vorbereitung legt man eine weitere Variable vom Typ SilcChannelEntry an, diese braucht man später, damit die letzte empfangene Nachricht einem Kanal zugeordnet werden kann, sowie eine SilcClientConnection, die für die gesamte Sitzung gilt.
Die weitere Entwicklung orientiert sich am Callbackmodell der libsilcclient. Nach der Eingabe der Passphrase, die auch leer sein darf (siehe Teil 1), wird zuerst der öffentliche Schlüssel des Servers überprüft. Es scheint, als müsse man im Callback silc_verify_public_key gar nichts weiter tun, denn nach ein paar Sekunden läuft der Prozess sowieso weiter, aber im Sinne des Erfinders ruft man die mitgelieferte Callback-Funktion auf:
(completion)(TRUE, context);
Als Warnung sei gesagt, dass sämtliche Überprüfungen in diesem 2. Teil des Tutorials wegfallen, denn die dahinterliegende Kryptographie ist noch einmal einen Teil für sich wert. Übrigens wertet auch Silky zwar den Schlüssel aus, liefert aber immer einen Erfolgscode zurück.
Als nächstes wird die Funktion silc_get_auth_method angesprungen, die anfragt, ob die Anmeldung des Nickname im Gastmodus, oder als registrierter Nutzer mit Passwort (wie im IRC) beziehungsweise unter Verwendung des öffentlichen Schlüssels stattfinden soll. Der Einfachheit halber sei hier mal die erste Methode verwendet:
(completion)(TRUE, SILC_AUTH_NONE, NULL, 0, context);
Und dann steht auch schon die Verbindung, allerdings sollte man in der entsprechenden Funktion darauf abprüfen, dass der Status SILC_CLIENT_CONN_SUCCESS ist, anderenfalls ist die gesamte Session über silc_client_close_connection abzubrechen . Der Server sendet dann jede Menge Benachrichtigungen, Statistiken und die Meldung des Tages (MOTD). Je nach SilcNotifyType kann man diese also ignorieren oder anwendungsspezifisch auswerten. Sobald das SILC_NOTIFY_TYPE_MOTD eingetroffen ist, kann man übrigens über
silc_client_command_call(client, connection, NULL, “JOIN", room, NULL);
den gewünschten Kanal betreten. Mit dem Meldungstyp SILC_NOTIFY_TYPE_JOIN ist auch dieser Vorgang abgeschlossen. Auf jedes abgesetzte Kommando bekommt man übrigens sowohl silc_command als auch silc_command_reply zurück, so dass man sowohl Fehler erkennen als auch zentral die Kommandos loggen kann, die ja von verschiedenen Punkten der Anwendung aus abgesetzt werden könnten.
Nachrichten kommen nun über die Callbacks silc_channel_message und silc_private_message hinein, während die Ausgabe erfolgt über:
silc_client_send_channel_message(client, connection, lastchannel, NULL, 0, token, strlen(token), TRUE);
Und das war es auch schon. Weitere Aktionen sind alle über die verschiedenen API-Varianten von silc_client_command_call durchführbar, die man ohne Slash (wie normalerweise im SILC-Client) angibt.
Vielen Dank auch an Astro für das Korrekturlesen :)