Protocol for Confcntlr to Forward Conference Bus Messages

  1. Message Types and Format
    Client/Requestor:
    Opens a TCP connection to confcntlr. Confcntlr listens for TCP connection requests on default port 62525. This port can be overridden with the command line argument "-p ". Requestor can then send requests to forward or cancel forwarding conference bus messages.

    Multiple message types can be combined within one request (delimited by "#"). "fwd" means to FORWARD messages of the given message-type to the specified address and host; "del" means to cancel (DELETE) relaying message-type messages to the specified address and port.

    REQUEST MESSAGE FORMAT:

    fwd (or del) requestor#message-type address port #message-type address port#...

    Examples:

    fwd mperry#focus 131.1.2.3 62525#focus disney.land.com 52323
    fwd mperry#all scooby.place.com 12345#adios 123.345.6.7 3456
    fwd mperry#release machine.domain.edu 3456
    del mperry#focus disney.land.com 52323
    Notes:
    "all" is a keyword that can be used if you want ALL conference bus messages to go to the specified address and port.

    If an address is added to a "fwd all" message AFTER it has been specified for some other message type, that address will receive duplicate copies of the message.

    Confcntlr:
    Receives request, enters message-type and address/port into linked lists, and sends a reply to indicate success/failure. Confcntlr is implementing the "authorization level" security feature shown in the "Security Window".

    REPLY MESSAGE FORMAT:

    request    code

    The request is echoed back in case replies arrive out of sequence. Codes are:

      0: success
    -1: error
    -2: remote control has been turned off (i.e., the authorization level is "allow no one")
    -3: badly formatted request
    -4: permission is denied for the particular requestor (either because authorization level is "allow authorized" and requestor is not on authorization list or requestor sent an unencrypted message to the version of confcntlr that supports encryption and has encryption activated)
  2. Source Code Notes
    Below is a summary of files and functions for handling conference bus messages.

    comm.c:
    TCP networking stuff--confcntlr calls make_connection() to send messages to remote hosts. read_str() and write_str() read from/write to TCP sockets.

    NOTE: Confcntlr reads/write in 2 steps: first it writes/reads length of message and then writes/reads "length" number of bytes. See comm.h for MSG struct.

    net-tcp.c:
    A Tcl/Tk interface to TCP networking functions. When confcntlr accepts a TCP connection (by invoking acceptConn() in net-tcp.c), it creates a file handler on the socket and when the socket is readable, processMessage() is called.

    processMessage() identifies the message type and calls the routine for that message type. When confcntlr receives a "fwd" or "del" message, it calls cb_forward(). cb_forward() checks authorization level and whether an encryption-supported version received an unencrypted message. If action is to be carried out, cb_forward calls msgListInsert() or msgListDelete() to add (or delete) message-types and/or address to lists. (See confbus.h for list structs and confbus.c for msgListInsert() and msgListDelete() functions.)

    confbus.c:
    Contains routines to open sender and receiver conference bus sockets (modeled after vic/vat's confbus.cc confbus.cc routines). dispatch() reads the message broadcast on conference bus channel and forwards the message to ipc_input. ipc_input() sends all conference bus messages to forwardMsg(). forwardMsg() walks linked list, matching the keyword "all" or the specified message-type. If either is found, the message is sent to all the addresses and ports associated with that message type.

  3. Comments and Future Work

    1. All host-to-host communication is via TCP. UDP may be implemented in the future.

    2. There are commented "printf" statements in processMessage() (net-tcp.c) and ipc_input() (confbus.c). These can be uncommented to display messages received by a remote peer or by vic/vat via the conference bus.

    3. There is a lot of linear searching with the present linked list implementation for associating conference bus message types and destination addresses. A mechanism for decreasing search/retrieval time (e.g., a hash table) may be implemented in the future.

    4. When a request comes in to "fwd" a message, the "all" message type's address list is searched to see if the specified host/port is already entered. This avoids some duplications. However, if a request, say to fwd 'focus' messages for machineX/portY comes in, and later confcntlr receives a request to fwd 'all' messages to machineX/portY, it doesn't search the entire list to see if that machine and port are already entered somewhere. (In this case, machineX/portY will get two copies of every 'focus' message.) I felt it was quicker for the client to order the request types than to add more list searching. This may be changed in the future.

    5. Confcntlr does not convert addresses, so a string and the dotted decimal form are considered different addresses. Address conversion may be added so that all addresses are of the same form when compared.