At 09:14 AM 1/23/2011, Jim Duuuude wrote:
Our architecture for Echolink differs a great deal from most others. Since there is no sane reason in the universe to do otherwise, our Echolink presence is both more-or-less a "conference", since it will ALWAYS accept multiple inbound connections and tie them together (as any connection is on an app_rpt node), and have the ability to support multiple outbound connections (also tied together with everything else on the app_rpt node) simultaneously. There is no reason to create "artificial" limitations of this nature.
Actually, there are reasons to create such limitations, but always under the sysop's discretion. A few examples might help. 1. Connecting to a node that blocks conferences. Do you advertise Asterisk as a conference all the time? Some of the time (i.e. only when there's more than one connection, which is what Echolink and thelinkbox do). 2. Conferences are not welcome on other conferences (i.e. multiconferencing). Do you have the ability to prevent Asterisk from multiconferencing? Why is this a problem, you may ask? Several years ago (actually, just before Hurricane Katrina), I realised that the most common cause of unintentional interference was caused by stations (-L, -R or PC user) having multiconferencing enabled. Someone would connect to these stations and then put out a call without taking time to listen to what's going on. In some cases, these people would actually connect and get out a call in between overs, blocking emergency or priority traffic in the process. As a result of these observations, some conferences have been running scripts that disconnect any station found to have multiconferencing enabled. 3. The number of stations allowed to be in conference is sometimes important, i.e. when upstream bandwidth is limited. It's better to block the next connection, than have everyone breaking up. All of these would need to be sysop configurable variables, and in that way, I agree that the software shouldn't contain any hard coded limitations, but sometimes, sysops need to be able to add their own limites to suit their situation.
Since the Echolink reporting system is really designed for implementation that basically do "one thing at a time", there is only a concept of a single status message. To make a (rather feeble) attempt at "fitting into the mold", I decided to report the "inbound" status when there are no outbound connections active. If outbound connections are active, it reports the information for the last one connected (if multiple outbound connections are active).
I had the same issues with EchoIRLP, because IRLP had no concept of multiple connections, so reporting the "connected station" was an exercise in reporting the most recently connected station, and hoping it made some kind of sense! :)
Therefore, by definition, the node can *never* be "busy" according to the Echolink reporting definition of "busy".
And yes, the "20" means "of 20 maximum connections". However, the connection limit was never implemented (after all, I try to avoid artifical limits on things). If and when there is a compelling reason do to so, I will. Currently, the system will take as many connections as there is bandwidth and CPU power for.
Or better still, put that in the hands of the sysop, since this is most likely to be site dependent. 73 de VK3JED / VK3IRL http://vkradio.com