IHUB

IHUB is an ADC extension used by qhub. It includes a set of modifications to allow multiple physical hubs to operate as one, much like IRC. qhub does not currently implement all of the specification, much like DC++ does with ADC.

New message types

• S command should be forwarded to all connected servers, but not passed on to clients. structure identical to that of type B
• L command is local to this connection, do not forward at all. structure identical to that of types I and H

SID Assignment

Each hub picks a 10-bit (2 character in BASE32) prefix, which must be unique in the network. The first two characters of all session id's assigned by that hub must match the prefix. This is to prevent race conditions in deciding what SIDs to give out. When a SID is needed for the hub, as in type S messages, "AA" is appended to this prefix to form the SID. Clients are not allowed to be assigned SIDs ending with "AA".

Handshake

IHUB handshakes are similar to BASE handshakes, except there is no IDENTIFY state. This is because passwords are dependent on the server, not the nick of the connecting client. Passwords are required. Here the client refers to the hub initiating the connection.

After the password check, each side should send its own INF (type S), followed by the SINFs of all other servers it is currently connected to, followed by the BINFs of all connected clients. In large hub networks, this can generate a large amount of traffic, so network administrators should be wary of creating too many new connections at once.

Additional INF parameters

Hub

• AD full address of hub's client port, e.g. "adc://hub.foo.com:1234" (for redirects, if necessary)

Normal operation

Messages of types B, D, and F are transparently (to the client) forwarded to connected hubs, which then distribute the command to the correct client. Hubs must take care to locally cache BINFs coming down the interhub connection so they are able to send the correct userlist to connecting clients.

Verification, however, should only be done by the hub the client is physically connected to; other hubs must trust this as verification is already taken care of by the password check at handshake time.

Network architecture

The network of connected hubs should be laid out in a spanning tree configuration, similar to the IRC protocol. See the IRC protocol RFC for a better explanation. The question of which servers connect to each other is at the discretion of the people running the network. Like in IRC, they will have the option of disconnecting and reconnecting servers to alleviate network congestion (though there are currently no facilities to do this).

TODO

• handling of I and H types
• what about keeping plugin data like banlists consistent across all hubs in a network?