Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
A
accord
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 39
    • Issues 39
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI/CD
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Create a new issue
  • Jobs
  • Issue Boards
Collapse sidebar
  • Accord
  • accord
  • Issues
  • #55

Closed
Open
Created Oct 08, 2010 by Patrick Dessalle@patd

Generated Virtual File Time stamp does not follow the specs

The Virtual File Time stamp currently not generated according to the specs. The specs (RFC 5024) say that HHMMSSccc means : HH : hours MM : minutes SS : seconds cccc : counter (0001-9999) which gives higher resolution.

Currently, the code is generating/parsing the cccc as milliseconds which by definition are limited to 3 digits (so the last c is always 0 and/or is not taken into account). This also means that the counter generates a unique counter number (limiting the protocol to 9999 messages per seconds).

So currently, the code could generate 2 messages with the same counter number if the messages are sent at the exact same millisecond (improbable but not impossible). And also technically the counter should be sequential (but nobody will care I think).

I currently need this counter to be correct to match the message that is sent and the EERP/NERP that is received.

I've set this to a minor priority. I believe that this should not be too complex to implement with a mutex for the counter but it shouldn't be an issue unless someone uses the system with some really heavy load (more than 999 messages a second or two at the same millisecond).

Assignee
Assign to
oftp-1.2.0.RC1
Milestone
oftp-1.2.0.RC1
Assign milestone
Time tracking
None
Due date
None