Re: [Svxlink-devel] singleton vs multiton
Brought to you by:
sm0svx
From: Andreas B. <ad...@bu...> - 2013-05-30 07:16:27
|
Hi Tobias & Sam, thank you for the response. Am 25.05.2013 09:40, schrieb Tobias Blomberg: > > The dispatcher was created as a singleton since it was assumed that a > single system would only have one EchoLink account. Using a singleton > makes it easier to decouple different parts in SvxLink that use > EchoLink. The idea was that multiple EchoLink modules in different > logics should be able to use the same dispatcher. I have also had in my > mind an "EchoLink Logic" which could be used to have a more permanent > connection to other EchoLink enabled repeaters. yes, this is comprehensible and ok for ~90% of all "normal" EchoLink-repeater/link-systems. > The real challenge begins when trying to figure out how to handle > incoming connections. One way is to let all incoming connections go to a > predefined logic core. This may not be desirable in all cases so another > approach is to let incoming connections go to all logic cores. But > again, this may not be desirable either since all logic cores would be > tied up when EchoLink connections are initialized externally. > > One improvement to make would be to add some "call pickup" function. > Incoming connections are announced on all logics and remote audio is > patched through. When someone pick up the "call", incoming audio will > only be distributed to the accepting logic core. A pickup could be > triggered by a local squelch open or a DTMF command for example. > > Another, easier and more straight forward, approach is to just accept > that all EchoLink connections go to all logics always, both incoming and > outgoing. No fancy features. I think this could be made better ;-) The best solution may be to separate the incoming/outgoing EchoLink-connections eachother and handle them independently (in my opinion). The handler should know which stations are already connected (callsigns) and able to share this information eachother. I would prefer your idea with the own logic for echolink. The module sourcecode can be moved to an own "EchoLogic", so there is no difference between a repeater, link, (phone), echolink, (sip), ... for users and system anymore and all of them is interconnectable eachother by request. If you have more than just one public ip you can configure two or more "EchoLogics". The logiclinking branch maybe a basic idea but has to be improved. At the moment no information about the source of an audiostream is transfered to the linked logic(s). vy 73's de Adi, DL1HRC > > This is how I have been thinking about multi logic core support for > EchoLink. I have not thought much about the case that multiple IP:s and > multiple EchoLink accounts were to be used. Of course, this is an easy > way out if one truly want each logic to have its own EchoLink "space". I > agree with you that it makes more sense to remove the singleton code > completely and create one instance for each EchoLink account. The > pointer to the dispatcher would have to be passed to the Qso object when > it's being created for example but that should be no big deal. > > One problem to consider when multiple logic cores use EchoLink is that > it may be easy to create audio loops if two cores that are connected to > the same EchoLink node is also connected internally in SvxLink by logic > linking. This problem may be easier to handle if using a single > dispatcher but I'm not sure. > > I'm a bit concerned though that changing the EchoLink code right now may > create conflicts with the EchoLink Proxy code. It may not be a problem > but I will probably not accept any patches to the EchoLink code until I > have merged the proxy code into trunk. I'll see if I can finish up the > elproxy branch today. > > 73's de SM0SVX / Tobias > > |