/usr/share/doc/libmeanwhile-dev/samples/readme is in libmeanwhile-dev 1.0.2-4.1ubuntu1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 | These samples demonstrate how to do a few things with the Meanwhile
library. Some of these are also tools which can be used to help in
debugging and obtaining protocol information.
Examples
========
socket.c
Compile with `./build socket`. This is the simplest possible
client. All it does is connect and authenticate to a host (specified
on the command line). Most of the code is dedicated to performing I/O.
sendmessage.c
Compile with `./build sendmessage`. Expands upon socket.c to send a
message via the IM service after login, then immediately logs off and
exits.
echo.c (forthcoming)
Compile with `./build echo`. This extends on the socket example above,
but introduces the use of the IM service. All incoming messages will
be echo'd verbatim back at whomever sends them. Can anger co-workers.
pipe.c (forthcoming)
Compile with `./build pipe`. Extending upon the echo example, but is
slightly more amusing and can be possibly useful for scripting. Will
output all incoming IM messages to stdout. Listens on stdin and will
write each line from stdin back to anyone who sent us a message
(responding in order received)
Since this application uses stdout, glib logging is smothered.
blist_storage.c (forthcoming)
Compile with `./build blist_storage`. An example of the Storage
service and buddy list parser. Operates in two modes, up and down. In
up mode, this sample will read a buddy list file on stdin, check it
for validity, then upload it to the storage service. In down mode,
this sample will fetch the buddy list from the storage service and
write it to stdout.
Since this application uses stdout, glib logging is smothered.
Utilities
=========
redirect_server.c
Compile with `./build redirect_server`. Acts as a redirecting sametime
server; any client attempting to connect to the socket this utility
listens on will be instructed to redirect its connection to an
alternative host (which is specified on the command line). Useful for
ensuring client code can handle redirects correctly when there's no
real redirecting server to test against.
nocipher_proxy.c
Compile with `./build nocipher_proxy`. Acts as a sametime server
proxy, passing messages between a real client and server. However, it
will intercept and mangle channel creation messages to ensure that
they will not be used with encryption. This will cause many clients to
fail in strange places (where they demand encryption), but is useful
for getting some messages from a service in the clear. Will print all
messages in hex pairs to stdout using the hexdump utility. This may be
more useful than using ethereal, as it will actually group its output
by message rather than by receipt from the TCP stream.
login_server.c
Compile with `./build login_server`. Acts as a sametime server; any
client attempting to connect to the socket this utility listens on
will be able to complete handshaking and send a login message. The
tool then analyzes the authentication method and data and prints the
decrypted data to stdout. This was useful for reverse-engineering the
RC2/128 auth method (and determining what one of the guint32 fields of
the handshake ack was for). Probably not very useful for anything
else.
logging_proxy.c
Compile with `./build logging_proxy`. Acts as a sametime server proxy,
passing messages between a real client and server. However, it will
intercept and mangle channel data in order to obtain the unencrypted
data. This should be invisible to both the client and the server. Will
print all messages in hex pairs to stdout using the hexdump utility,
and will print decrypted contents of encrypted channel messages
separately. This is certainly more useful than using ethereal, as it
groups its output by message as well as provides an unencrypted view
of otherwise obscured service protocols.
|