Hello Josh,
Yes, you are correct, it was simply a design decision and reasonable at
the time. However, with the knowledge that I have today of how networks
evolved that I did not have then, were I to do it over, I would add a
Bacula native persistent connection (using reconnection when the line
drops). In fact, the original design contains a sequential block number
that is not used, but was to be the basis for subsequent code that would
reconnect.
I appreciate your comments. Thanks.
Kern
On 6/10/20 5:41 PM, Josh Fisher wrote:
On 6/10/2020 8:04 AM, Kern Sibbald wrote:
Hello,
...
Now on the fact that line drops cancel jobs: First Bacula was
designed with the concept that it would have a stable communications
line as is supposed to be provided by TCP/IP, which Bacula uses.
This was a correct design based on networks at the time, but on
retrospect, I should have included comm line restarts in the original
design. In my opinion, the real problem is that modern switches for
all sorts of good reasons do not really support the original design
goals of TCP/IP.
I still feel that Bacula's design is correct. Yes, 802.3az changes the
always-on nature of a connection, allowing either side to temporarily
power down its transmitter to save energy, but the standard itself
doesn't change the original goal of a persistent connection. It is the
switch firmware and/or NIC device drivers that claim to support it,
but do not. It makes sense for Bacula to be as robust as possible, but
this is not a Bacula design flaw. It is a work-around for buggy hardware.
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
