message_daemon v0.63

Jason Gosnell
jason@jeff.ces.cwru.edu
Tue Mar 3 02:36:50 EST 1998


Introduction

message_daemon is designed to provide a means of exchanging BMessages with networked machines. The API parallels that of BMessenger in many ways; the primary difference being the specification of a remote machine with which to communicate.

message_daemon is freeware. Bug reports, feature requests, and other feedback can be sent to jason@jeff.ces.cwru.edu.


Security

As message_daemon allows networked machines to send BMessages of any content to any application, a security layer is provided so that only specified machines and applications may be allowed to send BMessages to local applications.

When message_daemon is launched, it looks for the "message_daemon settings" file in home/config/settings/; it will refuse to run if this file cannot be found. A simple settings file is provided in this distribution.

The format of the settings file is:

     [allow|deny]    [simple hostmask]    [allowed mime(s)]

The first parameter specifies whether to allow or deny the host/mime pair.

The second parameter is a simple hostmask. This mask is ANDed with the IP of any incoming connection, and if the result is the IP, the connection matches. In this manner, 255.255.255.255 will match everything, and 0.0.0.0 will match nothing. Access permissions are determined by the closest matching mask: 30.40.50.60 is a closer match to 30.40.50.60 than is 30.40.50.255. If no match is made, access is denied.

The third parameter determines which mimes are to be allowed/denied for the particular hostmask. The keyword "all" specifies all mimes.

Examples:
allow  30.60.90.180    all
allows remote messages from 30.60.90.180 to be sent to all mimes on this machine
deny   40.70.100.190   all
refuses all messages from 40.70.100.190
allow  50.255.255.255 
application/x-vnd.Avatar.BeBlurb
allows all IP's of 50.*.*.* to send messages to BeBlurb only

Some caveats:

This level of security is somewhat primitive compared to, for example, tcpd. Hostnames are not permitted in the mask field, and not all networks can be fully described with this simple masking notation. For most people, however, it should be sufficient for now.

message_daemon was about 30k before I added the security layer, which uses the C++ standard library. Currently, the C++ standard library is implemented in a large static library, causing the daemon to bloat to about 300k. When this library eventually becomes a shared library, the daemon size will shrink back down to 30k.

(And speaking of BeBlurb... Check it out!)


NetMessenger

Sample code from BeBlurb is now available and distributed with message_daemon, to illustrate using NetMessenger.a.

The NetMessenger.a library provides the interface that drives message_daemon. This interface is mostly congruent with that of BMessenger, with a few subtle and not-so-subtle differences.

The constructors require a destination address and a mime/team pair. Optionally, you may pass a pointer to a status_t for error detection and a bigtime_t specifying how long to wait for the connection to establish before timing out.

If a connection can't be established with the remote host, NetMessenger will return a B_ERROR via the status_t *. For a more descriptive error, call Error(), which returns a netstatus_t (see below).

Once a NetMessenger is constructed without error, a connection exists to the remote machine. To send a message, call one of the SendMessage() methods. If SendMessage() returns B_ERROR, check Error() to determine what went wrong.

On the remote machine, upon receiving a message, a reply NetMessenger object can be constructed with the constructor that receives a BMessage *. The connection is then shared between the sender and the replier (peer-to-peer).

The NetMessenger destructor initiates closes the connection if the other end isn't using it. If replies are being sent on the connection, the destructor of the replying object will close the connection.

Since message_daemon uses a connection-based protocol, the connection must be properly closed if the application owning the NetMessenger object that controls it somehow dies without disconnecting. For that reason, idle connections are closed after about five minutes. If you wish to keep a relatively idle NetMessenger object alive for extended periods of time, call the Ping() method occasionally to reset the idle. If Ping() returns B_ERROR, check Error().

If you need to determine to which remote address the NetMessenger object is connected, call GetRemoteHostname() with a preallocated char buffer.

netstatus_t

NET_OK
NET_NO_ERROR
nothing wrong
NET_ERROR generic error
NET_UNKNOWN_HOST the given hostname is unresolvable
NET_TIMED_OUT the connection attempt timed out
NET_CANT_CONNECT the connection request was refused
NET_CANT_REPLY the message doesn't contain a reply route
NET_DISCONNECTED the connection was broken
NET_LOCAL_ERROR something is wrong locally
NET_NO_DAEMON can't find a running messaging daemon
NET_INTERNAL_ERROR you should never see this one


To-Do:

Known Bugs and Limitations:

History

Changes since v0.62

Changes since v0.61

Changes since v0.6:


jason@jeff.ces.cwru.edu
Last Updated: 03 March 98