• BSO .try files

    From Wilfred van Velzen@2:280/464 to All on Mon Jan 25 15:30:18 2016
    * Originally in FTSC_PUBLIC
    * Crossposted in BINKD
    Hi All,

    FTS-5005.002 says about .try files:

    5.3. try control file

    This control file is created by a mailer when a connect
    attempt is finished - successful or not. It is named the same
    way as a flow file but with the extension ".try".

    An existing try file is replaced by a new one.

    A try file must contain one line string with a diagnostic
    message. It is for information purposes only.

    For information purposes the second line of a try file may
    contain one line of PID information. ( < 70 characters)

    Now I noticed that binkd is writing 5 binary bytes to a try file. Seems like some status information, plus the following string length.

    Is FTS-5005 not correct? Or does binkd have its own idea about try files?

    Bye, Wilfred.

    --- FMail-W32-1.69.12.144-B20160109
    * Origin: FMail development HQ (2:280/464)
  • From Pavel Gulchouck@2:463/68 to Wilfred van Velzen on Mon Jan 25 17:50:12 2016
    Hi Wilfred!

    25 Jan 16, Wilfred van Velzen ==> All:

    FTS-5005.002 says about .try files:

    5.3. try control file

    This control file is created by a mailer when a connect
    attempt is finished - successful or not. It is named the same
    way as a flow file but with the extension ".try".

    An existing try file is replaced by a new one.

    A try file must contain one line string with a diagnostic
    message. It is for information purposes only.

    For information purposes the second line of a try file may
    contain one line of PID information. ( < 70 characters)

    Now I noticed that binkd is writing 5 binary bytes to a try file. Seems
    like some status information, plus the following
    string length.

    Is FTS-5005 not correct? Or does binkd have its own idea about try files?

    Yes, binkd is not compatible with FTS. Thank you for the finding.

    I have no idea why FTSC published a standard which is not complies widely-used software.
    Files *.try and *.csy in BSO initially created by binkd many years ago as its private flags which did not conflict with any other BSO files. These are not informational flags, they contain technical information and are not intended for reading by people or by another software.
    FTSC documents which describe these files (in fact, another files with the same
    names) appeared much later.
    I do not think that binkd have to change its behaviour to comply FTS. IMHO FTS should be fixed according to practice.

    It's not first case when binkd suddenly contradicts FTSC documents. Binkd even violates protocol binkp as it's described by FTSC. I think that FTSC primary function is standardization of existing and used protocols to avoid incompatibility between software, but not invent new features and protocols that developers have to implement.

    And the worst case is when a developer implements some feature not clear, incompatible with an existing software. But if this developer is FTSC member, it's more simple for him to document his implementation as standard than fix it. He may think that his implementation is better, and it will be good if all another developers change this feature to his way.

    It's not hard to take another names instead of *.try and *.csy in binkd to avoid FTS incompatibility. But I'm sure that these names in FTS-5005 were obtained from binkd (directly or via some another mailer), so I'm not sure that
    if binkd will use another names, these new names will not occure in FTS the same way.

    Lucky carrier,
    Pavel
    aka gul@gul.kiev.ua
    --- GoldED+/LNX 1.1.5
    * Origin: II:CDLXIII/LXVIII (2:463/68)
  • From Michiel van der Vlist@2:280/5555 to Pavel Gulchouck on Mon Jan 25 17:10:41 2016
    Hello Pavel,

    On Monday January 25 2016 17:50, you wrote to Wilfred van Velzen:

    Is FTS-5005 not correct? Or does binkd have its own idea about
    try files?

    Yes, binkd is not compatible with FTS. Thank you for the finding.

    I have no idea why FTSC published a standard which is not complies widely-used software. Files *.try and *.csy in BSO initially created
    by binkd many years ago as its private flags which did not conflict
    with any other BSO files.

    The standard as published by the FTSC is based on older documents. FTS-5005 is mainly based on FSP-1034 which in turn is based on the T-mail and Bibkleyterm manuals.

    These are not informational flags, they contain technical information
    and are not intended for reading by people or by another software.
    FTSC documents which describe these files (in fact, another files with
    the same names) appeared much later. I do not think that binkd have to change its behaviour to comply FTS. IMHO FTS should be fixed according
    to practice.

    Just tell us how binkd deals with the .try en .csy files and we will adjust the
    documentation accordingly.


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20130111
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Wilfred van Velzen@2:280/464 to Michiel van der Vlist on Mon Jan 25 18:02:46 2016
    Hi,

    On 2016-01-25 17:10:41, Michiel van der Vlist wrote to Pavel Gulchouck:
    about: "BSO .try files":

    I have no idea why FTSC published a standard which is not complies
    widely-used software. Files *.try and *.csy in BSO initially created
    by binkd many years ago as its private flags which did not conflict
    with any other BSO files.

    MvdV> The standard as published by the FTSC is based on older documents. FTS-5005
    MvdV> is mainly based on FSP-1034 which in turn is based on the T-mail and
    MvdV> Bibkleyterm manuals.

    I've looked at the binkley documentation, and there is no mention of .try or .csy files
    I don't have anything on T-mail.


    Bye, Wilfred.


    --- FMail-W32-1.69.12.144-B20160109
    * Origin: Native IPv6 connectable node (2:280/464)
  • From Pavel Gulchouck@2:463/68 to Michiel van der Vlist on Mon Jan 25 18:48:46 2016
    Hi Michiel!

    25 Jan 16, Michiel van der Vlist ==> Pavel Gulchouck:

    Is FTS-5005 not correct? Or does binkd have its own idea about
    try files?

    Yes, binkd is not compatible with FTS. Thank you for the finding.

    I have no idea why FTSC published a standard which is not complies
    widely-used software. Files *.try and *.csy in BSO initially created
    by binkd many years ago as its private flags which did not conflict
    with any other BSO files.

    MvdV> The standard as published by the FTSC is based on older documents. FTS-5005 is mainly based on FSP-1034 which in turn is
    MvdV> based on the T-mail and Bibkleyterm manuals.

    AFAIK neither BinkleyTerm nor T-mail use *.try and *.csy files in BSO. This would cause inconsistency on systems with both t-mail/binkleyterm and binkd.

    These are not informational flags, they contain technical information
    and are not intended for reading by people or by another software.
    FTSC documents which describe these files (in fact, another files with
    the same names) appeared much later. I do not think that binkd have to
    change its behaviour to comply FTS. IMHO FTS should be fixed according
    to practice.

    MvdV> Just tell us how binkd deals with the .try en .csy files and we will adjust the documentation accordingly.

    *.csy are used a similar way to *.bsy but they set on start calling node, before handshake. It prevents simultaneous calls to the remote node by several binkd processes.
    I'm not sure it's good to standardize this due to two reasons: it's senseless to call a node by two binkd processes, but it may make sense to call a node by different protocols (i.e. binkd and ifmail or binkd and pstn). Then, binkd may use for this purpose another kind of IPC such as named semaphores in the future.

    Files *.try used for prevent infinite call to undialable nodes. Its format:
    16 bit: nok, number of good connects (bigendian)
    16 bit: nbad, number of consequent bad connects (bigendian)
    8 bit: comment length in bytes
    N bytes: comment

    nbad resets to zero on success outgoing connect.
    If nbad reaches some configurable value, node status set to undialable, created
    .hld flag, and both nok and nbad counters reset to 0.
    File .hld contains line with single number: unixtime until the node is on hold.

    I do not think that these files can be shared between mailers, because node undialable by one protocol can be available by another. These semaphores are private for binkd. May be it was not a good idea to create private mailer flags
    in common BSO.

    Lucky carrier,
    Pavel
    aka gul@gul.kiev.ua
    --- GoldED+/LNX 1.1.5
    * Origin: II:CDLXIII/LXVIII (2:463/68)
  • From Michiel van der Vlist@2:280/5555 to Wilfred van Velzen on Mon Jan 25 18:20:32 2016
    Hello Wilfred,

    On Monday January 25 2016 18:02, you wrote to me:

    MvdV>> The standard as published by the FTSC is based on older
    MvdV>> documents. FTS-5005 is mainly based on FSP-1034 which in turn
    MvdV>> is based on the T-mail and Bibkleyterm manuals.

    I've looked at the binkley documentation, and there is no mention of
    .try or .csy files I don't have anything on T-mail.

    They are mentioned in FSP-1034 which is over 10 years old.


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20130111
    * Origin: http://www.vlist.eu (2:280/5555)
  • From Michiel van der Vlist@2:280/5555 to Pavel Gulchouck on Tue Jan 26 01:03:50 2016
    Hello Pavel,

    On Monday January 25 2016 18:48, you wrote to me:

    MvdV>> Just tell us how binkd deals with the .try en .csy files and we
    MvdV>> will adjust the documentation accordingly.

    *.csy are used a similar way to *.bsy but they set on start calling
    node, before handshake. It prevents simultaneous calls to the remote
    node by several binkd processes. I'm not sure it's good to standardize
    [..]
    node undialable by one protocol can be available by another. These semaphores are private for binkd. May be it was not a good idea to
    create private mailer flags in common BSO.

    OK, thanks for the info. Give it some time to sink in. I will bring it up for discussion in the FTSC. Let me sleep on it.


    Cheers, Michiel

    --- GoldED+/W32-MSVC 1.1.5-b20130111
    * Origin: http://www.vlist.eu (2:280/5555)