Ndn-svs

Latest version: v0.3.17

Safety actively analyzes 682244 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 1 of 4

2.1

* Shared Sync Packet Signatures are Kept

2.0

* Security is Developed and Added

0.3.17

-
Simple Maintenance and Changes from minor. This includes modifying interests to be less strict (in case there's a time component) and includes the interest name in the case of a failure. (useful for debugging connection issues)

Like always, if you have any questions (even small ones), issues, or even concerns relating to this library or it's future; please reach out via an issue [here](https://github.com/justincpresley/ndn-python-svs/issues/new).

**_NOTE: It is heavily advised to try to keep ``ndn-svs`` up to date with the latest release._**

**Future Additions:**
-
* SVSync types are in the works see the docs!
* SecurityOptions will receive a healthy revisit
* Documentation will receive a heavy amount of additions for ease-of-use and overall coverage

0.3.16

-
Simple Maintenance and Changes from minor. This includes a proper clean error for publication limits, updated packages, and a doc page about types!

Like always, if you have any questions (even small ones), issues, or even concerns relating to this library or it's future; please reach out via an issue [here](https://github.com/justincpresley/ndn-python-svs/issues/new).

**_NOTE: It is heavily advised to try to keep ``ndn-svs`` up to date with the latest release._**

**Additions:**
-
> Usability
* added SVSyncPublicationTooLarge error when publishing something too large, noted by issue 9

> Libraries
* ndn-storage was much needed to be updated
* pycryptodomex was updated
* pytest was updated
* Sphinx and its typehints was updated

> Documentation
* added SVSync types page for users to see future uses


**Future Additions:**
-
* SVSync types are in the works see the docs!
* SecurityOptions will receive a healthy revisit
* Documentation will receive a heavy amount of additions for ease-of-use and overall coverage

0.3.15

-
Simple Maintenance and Changes from prototyping.

Like always, if you have any questions (even small ones), issues, or even concerns relating to this library's future; please reach out via an issue [here](https://github.com/justincpresley/ndn-python-svs/issues/new).

**_NOTE: It is heavily advised to try to keep ``ndn-svs`` up to date with the latest release._**

**Additions:**
-
> Tests
* Updated Tests (mainly typing)
* Added `state_table` testing

> Performance
* Added an extra variable which eliminates a extra re-occurring operation

**Deletions:**
-
> API
* no fetchDataPacket in Normal Sync: provides no use here.

**Future Additions:**
-
* Another SVSync type is in the works
* SecurityOptions will receive a healthy revisit
* Documentation will receive a heavy amount of additions for ease-of-use and overall coverage

0.3.14

-
In the past of this library, I have released updates that were neither fully tested nor were completely refactored for stability reasons. This puts applications using SVS in a _uncomfortable_ position. Therefore, I have decided that all updates will be ``stable`` going forward unless otherwise specified. This means that the **Future additions** being added will first be presented in the form of a **new branch** and undergo a **several week process**. This is my way of protecting bugs/vulnerabilities from being in the supply chain of your application.
Nevertheless , this release (while it does not add any additions) greatly impacts this library.

In this release, performance ended up taking over by a land slide with solid numbers to back it up.
NDN Encoding in Python is... much slower than C. I have been finding ways to mitigate this like storing the last wire to limit encoding. This time, I have been effective at doing this again. Instead of using the default Tlv Strutures, I simply do the encoding myself inside a __slots__ structure (to my knowledge the fastest way of accessing elements). I tested this _in-house way_ with the _previous structure_ more than 10 times and found that this _in-house way_ was roughly **11-14 milliseconds faster having 200+ entries**. This might not seem like much, but since this is a networking library; the difference is huge. I also changed various other things like forming a Statevector out of a Component which is not included in that measurement making this update be the biggest update dealing with performance.

In the long future, ``python-ndn`` might incorporate C for it's encoding or make other major encoding enhancements. If this happens, I will of course will go with the fastest option.

Like always, if you have any questions (even small ones), issues, or even concerns relating to this library's future; please reach out via an issue [here](https://github.com/justincpresley/ndn-python-svs/issues/new).

**_NOTE: It is heavily advised to try to keep ``ndn-svs`` up to date with the latest release._**

**Additions:**
-
> Requirements
* Updated ``sphinx-autodoc-typehints`` to the latest version.
> Performance
* More multi-var assignments
* Use ``Component`` instead of ``Name`` when creating and appending ``Components`` to a ``Name``.
* Forming a Statevector from a ``Component`` has dramatically been improved
* A Statevector now stores nids as strings instead of bytes due to majority of operations dealing with the nid as a string.
* In-house encoding / structure of a Statevector

**Bug Fixes:**
-
> Variables
* The ``Shared`` type now properly uses class variables instead of hardcoding values.

**Future Additions:**
-
* Another SVSync type is in the works
* SecurityOptions will receive a healthy revisit
* Documentation will receive a heavy amount of additions for ease-of-use and overall coverage

Page 1 of 4

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.