= Сообщение: 1273 из 7128 ====================================== FTSC_PUBLIC = От : Michiel van der Vlist 2:280/5555 07 Oct 14 16:33:58 Кому : Alexey Vissarionov 07 Oct 14 16:33:58 Тема : FTSC-5001 question FGHI : area://FTSC_PUBLIC?msgid=2:280/5555+543400b3 На : area://FTSC_PUBLIC?msgid=2:5020/545+54339d82 = Кодировка сообщения определена как: CP850 ================================== Ответ: area://FTSC_PUBLIC?msgid=2:292/854+a4000122 ============================================================================== Hello Alexey,
On Tuesday October 07 2014 12:00, you wrote to me:
AV> The "*" as the hostname and root-domain parameter are primarily AV> intended for single connections (like sending direct netmail when AV> routing doesn't work).
I prefer the other way around. I send direct when possible and route when direct is not possible.
AV> Permanent links should (in the meaning from AV> FTA-1006: do that, unless you have really strong reasons for not AV> doing) be explicitly configured
That is how I have done it. My permanent links - the one I have a secure connection with - are in nodes.cfg, an include file for binkd.cfg.
AV> to use all known information: all hostnames from nodelist and, AV> possibly, literal IP addresses (just in case of DNS failure or domain AV> expiration).
I prefer to not use literal IP addresses and use only host names instead. DNS failures are rare and many IP adresses are dynamic anyway. A much more frequent event is that a node is temporary off-line. If one enters both the host name and the IP address, binkd will just needlessly try both if the node is off-line.
AV> For example, your node is listed in my binkd.links as:
AV> That means, my node will try to resolve fido.vlist.eu first (as this AV> hostname appears in the nodelist), but if that fails, it will try both AV> IPv6 and IPv4 addresses
If fido.vlist.eu fails, ninetynine times out of hundred the IP address will fail as well. The DNS service for vlist.eu is much more reliable then my own system. Tha added value is small.
AV> (once known to be static).
Not really. It s a dynamic address, but it only changes when the MAC address of my router changes.
MvdV>>>> The nodelist is the primary source of Fdionet connection MvdV>>>> information. All the information to make a connection MUST MvdV>>>> be present in the nodelist. DNS distributed nodelists as MvdV>>>> documenetd in FTS-5004 are an /additional/ service, not a MvdV>>>> replacement for the nodelist. ml>>> agreed on both accounts... MV>> So a protocol flag without an associated host name or IP number MV>> in the nodelist is an error.
AV> As FTSC, we should point ZCs at this error...
Yes, we should. Unfortunately not all *Cs are equally responsive...
MV>> You know, you don't HAVE to list all your connections in the MV>> nodelist. It is not a MUST. All that is required is that you list MV>> /a/ connection method that will let others connect to you. This MV>> is an amateur network. No one will hold it against you if you can MV>> not offer 100% connectivity.
AV> Hmmm... I'm about to reach 99.995% - less than 2 months left. And AV> reaching 99.999 is on my agenda :-) Well, as a HL/HA system architect AV> I have both knowledge and ability for that (main server is rented, AV> backup server is at my home).
Good for you. ;-)
MV>> It is OK to only publish the more obscure connectiom methods to a MV>> limited number of selected parties.
AV> Once I tried FTN connection over binkp over tcp over AX.25 over UHF AV> radio. However, that's not the connection method I'd like to publish AV> in the nodelist.
I have experimented with transfering data over HAM radio. They were interesting experiments. It is not suitable for Fidonet though. There are legal problems. Plus that there is no place for the frequency in the nodelist. ;-)
MV>> In fact here this was not unusual in the POTS age. Several MV>> nodes/BBSs here in The Netherlands had two telephone lines. But MV>> only one of the numbers was published in the nodelist. The other MV>> number was only given to preferred users/points. The second line MV>> did not need to observe ZMH of course. So users could continuue MV>> to be served all night.
AV> Another option was to use these hidden lines for outgoing connections.
Especially if you can get your boss to pay the bill. ;-)
