I get a lot of out of zone netmail as a ZC and will forward that to my colleague ZCs in other zone from where it trickles down to final destination. I also handle a lot of netmail for all other regions,
easy, I'm in touch with all RCs by default, hence I can assure a guaranteed delivery.
the day I became a ZC and that has worked without complaints since
day-1 ... that was now close to 27 years ago.
Feel free to disagree.
Over the years I have set up direct links with almost all of the Z2 RCs and with some in other zones. I prefer to deliver netmail as close to the destination as possible and practical. Less hops, less potential problems. These bypasses to my fellow RCs are used for that purpose.
You do not have a direct-link here and have not for quite some time despite your outright bullshit claim in another echo.
That is the beauty of Fido over IP. There is no problem. No one is dependan on one particular link. If some arrogant asshole no longer wants to link wi me, I just route around him/her. I have plenty of direct links into Z1 to n need you.
You do not have a direct-link here and have not for quite some time
despite your outright bullshit claim in another echo.
That is the beauty of Fido over IP. There is no problem. No one is
dependan on one particular link. If some arrogant asshole no
longer wants to link wi me, I just route around him/her. I have
plenty of direct links into Z1 to n need you.
Okay soooo.... why the need to insult Ward's system then in the first place,
Lemme guess - because "you can".
I'm in touch with all RCs by default, hence I can assure a
guaranteed delivery.
With all due respect, no such guarantee can be given.
... There is no known
co-sysop for your system so if it crashes during your absence nothing can be done. In the past that has happened on more than one occasison.
And despite some outright bullshit claim, the zone war goes on...
You do not have a direct-link here and have not for quite some
time despite your outright bullshit claim in another echo.
And despite some outright bullshit claim, the zone war goes on...
MvdV>> Indeed, I do not have a direct link with you. I did in theYou do not have a direct-link here and have not for quite some
time despite your outright bullshit claim in another echo.
And despite some outright bullshit claim, the zone war goesFidonet will never die. In the end it will come down to two old men fighting about how they send mail to each other
on...
Having said that, I do not think what we see here is the return of the zone war. This is merely an issue with the person presently carrying the Z1C hat and and some sysops who do not like his style. Obviously the ZC1 is not a diplomat. But his undiplomacy is not just aimed at me or other Z2 sysops. Z sysops are on his radar as well. It happens. Ever so often technicians are lousy diplomats. Of course that does not work the other way around. Being a lousy diplomat does not necessarilly make a good technician.
MvdV>> Indeed, I do not have a direct link with you. I did in theYou do not have a direct-link here and have not for quite some
time despite your outright bullshit claim in another echo.
MvdV>> past, but it was discontinued on your "request".
And despite some outright bullshit claim, the zone war goesFidonet will never die. In the end it will come down to two old men fightin about how they send mail to each other
on...
Fidonet will never die. In the end it will come down to two old men fighti about how they send mail to each other
I'm far from old...
I don't get what all the bitching is about? Posts come in, posts go out. if 3000 dupes are being tossed in, that's a different story. Other than tha I see no issues, just tons of bitching.
With all due respect, no such guarantee can be given.
You really need to read what it says, not what you think it says.
Following the network-tree is the way to send netmail ... the *C-structures are vertically in touch with eachother and netmail will arrive....
I guarantee delivery ... If a netmail does not reach me, of course it
will not be delivered. But when I get it, I have a delivery option
which works...
... There is no known co-sysop for your system so if it crashes
during your absence nothing can be done. In the past that has
happened on more than one occasison.
You are not wrong here, of course. "on more than one occasion" is
probably right ... so was that more than 2 occasions, or just 2? I'm calculating a reliability of 99,68% ... not bad, not bad at all.
"netmail will arrive", that is what you wrote.
I distrust figures that suggest four digit accuracy without further substantiation. I am not going to argue about on how many occasions your single Point of Failure has indeed failed. Two or ten times, I have
better things to do then delve into the archives. The point is, it IS a SPOF and SPOF is to be avoided when possible.
*1) It is not really a tree. It is more like a pyramid, or an inverted tree. The "root" ia at the top, not at the bootom.
LOL. I'm not here to be liked or be diplomatic or even get along with anyone.
There are very specific things I do in Fidonet and entertaining your masturbatory fantasies is not one of them. The more you rant about a zone-war the more it says about your secret desire to have one...
Everyone gets "one chance" with me, including you. You blew that not
by insulting me over a lack of IPV6
but rather when you decided to accuse me of acting on in-transit
Netmail after Ben Ritchey died.
Whatever your mental-hangup is, maybe its a Dutch thing... I don't
care two shits. When you and some others make the grand-departure I
will not give two shits either.
Whatever. Apart from the SPOF, all the more reason to avoid your system wh routing netmail.
[..]The point is, it IS a SPOF and SPOF is to be avoided when possible.
I think I had a major disc crash in 2006 ... Janis helped me recover
from that ... in 2014 there was a power surge for reasons never
5 years of smoothness since (touch wood). That's what I remember and
that time when my wife destroyed the telephone wall outlet with the
vacuum ... don't think it lasted a day...
Hello Ward,
On Monday June 07 2021 11:11, you wrote to me:
Mv>> The point is, it IS a SPOF and SPOF is to be avoided when possible.
WD> I think I had a major disc crash in 2006 ... Janis helped me recover
WD> from that ... in 2014 there was a power surge for reasons never
[..]
WD> 5 years of smoothness since (touch wood). That's what I remember and
WD> that time when my wife destroyed the telephone wall outlet with the
WD> vacuum ... don't think it lasted a day...
My notoriously unrelyable memorie tells me there were more incidents. What I am sure about is April 2020 during your Covid misadventure. You may have missed this entirely. Your binkp server answered calls and accepted data, but mail was not processed. No reply to PING and your areamanager did not respond either. The system was turned into a black hole. Mail was /not/ delivered.
This is not an objurgation. I am not blaming you in any way. I am just reporting what was observed. We run an amateur network and things happen. We can not be asked to make large investments to insure against all possible mishap.
The consequence is that there are no guarantees. Nobody can /guarantee/ delivery. Having said that: putting all the eggs in one basket is indeed not a good idea.
Whatever your mental-hangup is, maybe its a Dutch thing... I don't
care two shits. When you and some others make the grand-departure I
will not give two shits either.
What we have achieved is that there still is a Fidonet for you to
return to.
What we have achieved is that there still is a Fidonet for you to
return to.
I appreciate it. Thank you all sysops, *Cs and everyone else who have
kept Fidonet afloat.
Also a big THANK YOU to the developers that have ported, enhanced, maintained, supported and created FTN software all these years.
just from a technical perspective: what is the difference between a
normal mailer over telnet and binkp? (ok, maybe encryption)
because in '90something i was already using my xenia over IP and
carried a huge amount of international traffic to the hungarian backbone
Not trying to be Captain Obvious but D'Bridge was never designed with TCP connections in mind.
That said... a few months ago I tested D'Bridge with Frontdoor via TCP with the help of TJ Mcmillen at 1:129/305 when he had it
running... we traded packets perfectly. The Zmodem "turnaround" you mention was there but worked.
Has it always worked this way? I can see reading FSC-0056 that it may be interpretted to operate this way (early in the document), but later in the
Has it always worked this way? I can see reading FSC-0056 that it may be interpretted to operate this way (early in the
document), but later in the
The code appears so, at a first glance. Since D'Bridge works perfectly with EMSI on dialup with all other mailers, and as explained
it worked perfectly with Frontdoor via. TCP, and it was the original author and JoHo who invented the whole thing... I'm not sure
how you want me to answer this. It could also be that the way JoHo documented FSC-0056 may differ from the implementation.
You did not explain what version of D'Bridge you were using or how exactly you are testing things nor did you indicate you tested
others in the same manner.
My "modem" is tcpser - with the serial port side going to DBridge - DBridge uses COM2. The TCP side receives IP connections from other mailers. (My FrontDoor and Portal are configured the same way as DBridge).
I'm running dosemu on 1 system and qemu/MSDOS on another, although I've bee doing most of my playing in dosemu, since I'm connecting successfully to everthing (except DB).
I very clearly wrote in the documentation what the supported OS's and modems are and what you're describing is not any of them.
You're seemingly making it a point to run my software on an unsupported OS with some unsupported weird virtual-modem thing. Then complaining in this echo (instead of Netmail or the DBRIDGE echo) that it "doesn't work", yet it "does work" and has
worked for many thousands of Sysops since '91.
This is another reason why I don't know how to answer you.
Standing back and looking at the bigger picture - I doubt many people are using EMSI these days over a serial interface, and I see you putting out updates often - thus my line of questioning was to probe to see if anything that you "changed" may have affected that implmentation. Especially since
Has it always worked this way? I can see reading FSC-0056 that it may be interpretted to operate this way (early in the document), but later in
the "sequence definitions" it shows that each EMSI_* command should be terminated with CR (and references earlier that this is a trigger to
flush buffers.)
If Nick hadn't spread the rumour that I am lying about helping him port entire code from TP5 to TP7, including removing loads of crazy DOS code, I might help him clean up the EMSI part as well, but as you can understand, that'll not be happening...
And you are right. I just checked the source code (the one that some people deny that I have) and there are several parts where DB
is doing it all wrong. One part is the CR case that you have found. Impressing! Kudos!
Then again, I can understand that the present maintainer is reluctant to touch the EMSI code. The DBEMSI.PAS file alone was more
than 47kB in November 2005 when he asked me to help him clean up the code (also denied after I did -- albeit not this part).
If Nick hadn't spread the rumour that I am lying about helping him port the entire code from TP5 to TP7, including removing loads
of crazy DOS code, I might help him clean up the EMSI part as well, but as you can understand, that'll not be happening...
| Sysop: | xxorz |
|---|---|
| Location: | Holly Springs, NC |
| Users: | 4 |
| Nodes: | 11 (0 / 11) |
| Uptime: | 201:20:55 |
| Calls: | 19 |
| Files: | 4,481 |
| Messages: | 620,058 |