Synchronet v3.19b-Win32 (install) has been released (Jan-2022).

You can donate to the Synchronet project using PayPal.

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revisionBoth sides next revision
wiki:user:digital_man [2019/10/31 20:03] – Things I learned while interviewing for programming jobs in 2019 digital manwiki:user:digital_man [2021/12/31 11:08] – [Digital Man's blog] digital man
Line 1: Line 1:
-====== Digital Man's blog ======+====== Digital Man's Web Log ====== 
 + 
 +===== What's Wrong With FidoNet? ===== 
 + 
 +And by "FidoNet", I'm not referring to the message network itself but rather the underlying technology (aka FTN). 
 + 
 +Before you can "fix" something or just replace it with something better, you really should have a comprehensive, enumerated list of what's wrong with the existing "solution". 
 + 
 +This list is of course, just //my// opinion, but it is an informed one with about 30 years of experience with FTN from both a user/sysop's perspective and a developer. 
 + 
 +==== Backward Compatibility ===== 
 + 
 +Likely the biggest problem with FTN is that much of the software that is used to run the network is abandonware with no hope of being upgraded to support any substantial improvements in the underlying network technology. Most substantial improvements to the network technology would leave a lot of existing nodes behind and hamper the possibility of retro-systems being able to join and participate in FidoNet. The requirement of strict backward compatibility with software written in the 1980s and 1990s is the pervasive rationale of the FidoNet network members for not accepting proposed solutions to the network technology's shortcomings. 
 + 
 +The one saving grace has been extensibility via the message "control paragraph" (aka "kludge line"). Since it was specified early on that message lines beginning with a Ctrl-A (ASCII 1) character must not be displayed, as they contain "control information", this has been the scheme by which additional or improved message header fields have been added over the years. Unrecognized control lines are ignored by receiving software and thus backward compatibility can be maintained while still defining and using new control lines in messages created and consumed by newer FTN software. 
 + 
 +==== Location-based Addressing ==== 
 + 
 +The geographic location of the FidoNet node (continent, region) is encoded in the node address. While this is true of IP addresses as well, the Internet has a handy solution called the DNS. While I do like that it's obvious to an experienced BBSer that it's a FidoNet address when you see one (e.g. "1:103/705.1"), it's certainly non-intuitive what all the symbols and numbers mean and is not easy to remember. An addressing system that uses human-readable (and memorizable) "words" for the addresses of the network nodes would be much preferred. 
 + 
 +==== Packet Format ==== 
 + 
 +The standard [[ref:FidoNet Packets|FidoNet Packet format]] (so-called "type-2" or "stone age" packet format) was originally specified and accepted as the FidoNet standard in 1987 and hasn't really progressed much since then. Although there were a few proposed packet format replacements twenty-plus years ago, none of them were accepted as a standard. There have been some incremental improvements to the type-2 packet definition (FSCs 39, 45, and 48) and while FSC-48 ("Type-2+") has long been the majority-preferred packet format, none of these improvements has been ratified as a formal standard. 
 + 
 +The problems with the Type-2 packet format and its derivatives (and their "packed message" format) are: 
 +  - Lack of extensibility (no real way to substantially add more header fields or extend the length/range of any already-defined header fields) 
 +  - US-ASCII only text field with no support for using Unicode or other character sets 
 +  - DateTime header field format that is plain text with 2-digit year 
 +  - Artificially limited string lengths (i.e. 35 characters names, 71 character subjects, 8 character passwords) 
 +  - Relying on NUL-terminated (ASCIIZ) strings (most of the time) 
 +  - Little-endian integers (x86 architecture assumed at the time) 
 +  - Reliance on echomail "origin line" for the originating address 
 + 
 +==== Siloed Development ====
  
 ===== Why BBS? ===== ===== Why BBS? =====

Trace: