|
Erm. Not quite. What happens is this. When an IMC mud connects to the hub, for any reason, it sends an even to the hub telling it to deliver the first channel "refresh" after 30 seconds. What then happens is the hub returns a pair of channels after the first 30 seconds. This "refreshes" the data for who owns it, moderates it, etc. Then IN THEORY the hub sends another pair down every 30 seconds until it's done. However, for reasons unknown, this fails to happen sometimes and the mud can be made to wait for as long as 10 minutes. And until a channel is refreshed, the mud simply can't use it.
This whole procees repeats even if the mud uses copyover, due to the nature of the protocol.
What sets I3 apart is that after it sends the initial startup_packet, it gets the startup_reply packet back within about 5-10 seconds. Shortly thereafter, the list of current channels is sent down to update the mud's list. BUT - the mud has a list of channels which are locally subscribed and these can be used from the moment that startup_reply comes back. No need to wait for the refresh. The advantage with this goes even further on muds equipped with copyover. The I3 socket can be passed as an argument to the execl() call and thus makes it available instantaneously after that's done, and even buffers incoming channel messages while the copyover is in progress.
|