an efficient feature complete C++ bittorrent implementation

docs/img/logo-color-text.png


https://ci.appveyor.com/api/projects/status/w7teauvub5813mew/branch/master?svg=true https://api.cirrus-ci.com/github/arvidn/libtorrent.svg?branch=RC_2_0 https://img.shields.io/lgtm/alerts/g/arvidn/libtorrent.svg?logo=lgtm&logoWidth=18 https://codecov.io/github/arvidn/libtorrent/coverage.svg?branch=master https://img.shields.io/lgtm/grade/cpp/g/arvidn/libtorrent.svg?logo=lgtm&logoWidth=18 https://www.openhub.net/p/rasterbar-libtorrent/widgets/project_thin_badge.gif https://bestpractices.coreinfrastructure.org/projects/3020/badge

libtorrent is an open source C++ library implementing the BitTorrent protocol, along with most popular extensions, making it suitable for real world deployment. It is configurable to be able to fit both servers and embedded devices.

The main goals of libtorrent are to be efficient and easy to use.

See libtorrent.org for more detailed build and usage instructions.

To build with boost-build, make sure boost and boost-build is installed and run:

b2

In the libtorrent root. To build the examples, run b2 in the examples directory.

See building.html for more details on how to build and which configuration options are available. For python bindings, see the python docs.

libtorrent ABI report.

libtorrent package versions in linux distributions, on repology.

Comments
  • WebTorrent support

    WebTorrent support

    This PR suggests an implementation of the WebTorrent protocol inside libtorrent. With this add-on, libtorrent can be used to run hybrid peers seamlessly.

    WebTorrent peers use the same application protocol as classic peers but with WebRTC Data Channels as underlying transport instead of uTP or TCP, allowing to run peers in web browsers. Due to the necessary connection signaling, WebTorrent peers require a specific WebSocket tracker to connect.

    Since documentation seems to be lacking, I implemented the WebTorrent signaling protocol the best I could guess by looking at existing code. You can find useful information and the reference Javascript implementation here: https://github.com/webtorrent/webtorrent

    The implementation requires two external dependencies added as submodules:

    • libdatachannel, my lightweight WebRTC Data Channels implementation, which relies on my ad-hoc UDP Interactive Connectivity Establishment (ICE) library libjuice
    • boost.JSON, a header-only JSON library for the tracker protocol

    This PR does not add new external dependencies to libtorrent (it only requires OpenSSL or GnuTLS depending on the compilation option).

    To test, you need a torrent file with at least one WebSocket tracker, for instance wss://tracker.openwebtorrent.com. You can find such a torrent file here: https://ageneau.org/upload/sintel.torrent You can also run a web browser peer on this page: https://webtorrent.io/

  • Support WebTorrent Protocol

    Support WebTorrent Protocol

    WebTorrent is a new implementation of the bittorrent protocol designed to work over WebRTC. This allows browsers to download torrents without plugins. However, due to the limitations of WebRTC it isn't possible to make the protocol compatible with bittorrent (or uTP).

    If libtorrent supported WebTorrent it would be able to communicate with both the existing swarm as well as the browser swarm that is restricted to WebTorrent only.

  • Poor uTP performance

    Poor uTP performance

    When I seed a single 5GB file from an AWS server in Australia using the newest uTorrent version - to a single peer in Norway I get 2-3 megabyte/sec speed - which is pretty good compared to other UDP based transfer acceleration protocols. Flags in uTorrent on the peer side in Norway shows that uTP is used. The latency is about 350ms.

    When I seed the same single file using libTorrent 1.1.0.0 I end up with approx 150-500 kbyte/sec. Flags in uTorrent on the peer side in Norway shows that uTP is used here as well. I am running vanilla settings for libTorrent - the only settings specified are seedmode = true and automanaged=false.

    So it seems to be a uTP (UDP) performance issue with libtorrent?

    I also saw a similar issue here where you are in the loop @arvidn : https://github.com/Tribler/tribler/issues/2620

    What do you think?

    libtorrent version (or branch): 1.1.0.0 platform/architecture: Win - x64 - static MT compiler and compiler version: VS2017 - toolset v.141

  • trackers do not work in 1.2.4 with qbittorrent, 1.2.3 was ok

    trackers do not work in 1.2.4 with qbittorrent, 1.2.3 was ok

    libtorrent version (or branch): 1.2.4

    platform/architecture: x86_64 Linux Fedora 30

    compiler and compiler version: gcc 9.2.1

    When using qbittorrent 4.3.0-git with libtorrent 1.2.4, qbittorrent reports that none of the trackers work. Switching back to libtorrent 1.2.3 makes everything work just fine. Unfortunately qbittorrent does not produce any logs.

  • Add a cibuildwheel workflow

    Add a cibuildwheel workflow

    This adds a cibuildwheel workflow.

    Features

    • Builds and tests wheels in 28 flavors
    • Can be run manually, with an option to upload to pypi
    • ~~Will run automatically when a release is published, unconditionally uploads to pypi~~
    • If a PR touches cibuildwheel infrastructure (cibuildwheel.yml or tools/cibuildwheel/**), we will test by building a representative sample of wheels (the full suite of wheels takes hours)
    • Caches build artifacts, so re-runs are fast

    Changes

    • ~~The python project name is changed from python-libtorrent to just libtorrent. Closer to common practice in python, plus the name was available on pypi~~
    • ~~Other changes to setup.py, following the principle that --config-mode=distutils should create a wheel-suitable build by default~~

    Tests

    I patched this (and other dependent build system changes) on the v1.2.14 and v2.0.4 tags. I uploaded the wheels to test-pypi:

    • https://test.pypi.org/project/libtorrent/2.0.4.post3/
    • https://test.pypi.org/project/libtorrent/1.2.14.post3/

    Release procedures and notes

    • @arvidn should create a pypi API token restricted to the "libtorrent" project, and add it as a github actions secret (PYPI_API_TOKEN)
    • EDIT: also create an API token on test-pypi restricted to the separate "libtorrent" project there, and add it as a github actions secret TEST_PYPI_API_TOKEN
    • I already registered the project on pypi (EDIT: and test-pypi), and invited @arvidn as an owner

    Proposed release procedure:

    • before you create a release, manually run the cibuildwheel workflow without publishing to pypi, to make sure everything builds
    • If everything builds, run the workflow again and publish to pypi. ~~Or just create the release, and the workflow will publish automatically.~~

    Release procedure caveats

    NOTE: pypi uploads are immutable, and filenames cannot be reused even after files are deleted. Publish with care!!

    • I already uploaded some files for libtorrent 2.0.4, then deleted them, not realizing those filenames can never be used again
      • If desired, this could be remedied by publishing a 2.0.4.1 release
    • It's good practice to upload to https://test.pypi.org/ before uploading the "production" index at https://pypi.org/
    • ~~But "libtorrent" at test-pypi is held by someone else, I believe by github user @mayli~~
    • ~~I have contacted @mayli by email to transfer ownership of the test-pypi project~~ EDIT: mayli transferred ownership of the project, thanks!

    Build Flavors

    • cp37-cp37m-macosx_10_9_x86_64
    • cp37-cp37m-manylinux_2_12_x86_64.manylinux2010_x86_64
    • cp37-cp37m-manylinux_2_17_aarch64.manylinux2014_aarch64
    • cp37-cp37m-musllinux_1_1_aarch64
    • cp37-cp37m-musllinux_1_1_x86_64
    • cp37-cp37m-win32
    • cp37-cp37m-win_amd64
    • cp38-cp38-macosx_10_9_x86_64
    • cp38-cp38-manylinux_2_12_x86_64.manylinux2010_x86_64
    • cp38-cp38-manylinux_2_17_aarch64.manylinux2014_aarch64
    • cp38-cp38-musllinux_1_1_aarch64
    • cp38-cp38-musllinux_1_1_x86_64
    • cp38-cp38-win32
    • cp38-cp38-win_amd64
    • cp39-cp39-macosx_10_9_x86_64
    • cp39-cp39-manylinux_2_12_x86_64.manylinux2010_x86_64
    • cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64
    • cp39-cp39-musllinux_1_1_aarch64
    • cp39-cp39-musllinux_1_1_x86_64
    • cp39-cp39-win32
    • cp39-cp39-win_amd64
    • cp310-cp310-macosx_10_9_x86_64
    • cp310-cp310-manylinux_2_12_x86_64.manylinux2010_x86_64
    • cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64
    • cp310-cp310-musllinux_1_1_aarch64
    • cp310-cp310-musllinux_1_1_x86_64
    • cp310-cp310-win32
    • cp310-cp310-win_amd64

    Missing flavors

    Flavors we'd like to build but can't

    • macos arm64
      • the x86 macos runners can cross-compile, but I can't seem to make it work. We are invoking b2 architecture=arm address-model=64 which should be right, but there are still link errors about mixing x86_64 objects.
      • macos on x86_64 cannot run or emulate arm64 code, so these builds can't be tested until there are m1 mac runners
    • macos universal2
      • b2 architecture=combined address-model=64 does not build this (should pick -arch x86_64 -arch arm64), even in boost 1.77.0. I tried cxxflags="-arch x86_64 -arch arm64", but the compiler says these flags are unused.
      • as above, these can't be tested until there are m1 mac runners. apparently mac on m1 can emulate x86_64, so universal binaries can be tested on a single runner, just not the runners we have
    • ~~musllinux~~
      • ~~this is new, and cibuildwheel doesn't support it yet~~ EDIT: the latest cibuildwheel supports this!
    • pypy
      • the python bindings don't build with this. I'll investigate

    Other flavors

    The build times already take hours, and the artifacts are large due to static linking, and pypi has finite hosting space. We should add flavors as requested, rather than building everything.

    Python 3.6 will reach end of life in 2021-12, so I've preemptively removed it from the list to shorten build times. numpy has already done this in their most recent release

    Future optimizations

    The builds currently take hours on aarch64 and other emulated architectures. It would be nice to reduce this.

    abi3

    The biggest win would be to use abi3 which would let us produce one build per platform rather than building for every python version. However

    Prebuild dependencies

    • openssl and boost-python (in all python versions) are built from source every time. We could cache them somewhere. On linux, using actions/cache is difficult because the builds run in docker. The right approach is probably to build a custom docker image with prebuilt dependencies. This would especially cut down build times for aarch64 and other emulated architectures.

    macos ccache

    We build artifacts for a given platform sequentially in a single job, which lets us use ccache. On the Linux builds this works well today.

    On mac, ccache reports 0% hit rates between builds for some reason. The only thing that changes is the python version. We should investigate this.

    windows ccache equivalent

    On Windows, there is no build caching. It would be nice to have. However the Windows builds already complete in ~40 minutes, so this is a smaller gain compared to others.

  • Not working without a sparse mode

    Not working without a sparse mode

    I checked. The library shows that there are peers, but it doesn't download anything. Most devices in the world do not have sparse mode. It's an obvious library bug.

  • LibTorrent remains connected to peers and seeds even when stalled

    LibTorrent remains connected to peers and seeds even when stalled

    libtorrent version (or branch):

    qBitTorrent 4.3.1 LibTorrent 1.2.11.0

    platform/architecture: Windows 10 64-bit

    LibTorrent remains connected to peers and seeds even when stalled because connected clients do not have any more torrent chunks to send.

    image

  • libtorrent 1.1.{7,8,9} + Deluge 1.3.15, connecting only to small fraction of peers over dozens and only on certain trackers

    libtorrent 1.1.{7,8,9} + Deluge 1.3.15, connecting only to small fraction of peers over dozens and only on certain trackers

    Please provide the following information

    libtorrent version (or branch):

    • 1.1.7
    • 1.1.8
    • 1.1.9

    platform/architecture: Debian GNU/Linux 9, x86_64

    compiler and compiler version:

    gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516

    please describe what symptom you see, what you would expect to see instead and how to reproduce it.

    This issue was originally posted on Reddit r/seedboxes. I am summarizing it here.

    Deluge with the 1.1 branch of libtorrent (confirmed on .7, .8, and .9). Snatching torrents with autodl irssi on IPT and TL trackers.

    After seeing the first Announce OK message (not related to the unregistered torrent issue in #315; workaround on that works fine), Deluge connects to only a small fraction of peers. Usually 2 to 5 over confirmed swarms of dozens (also 60+). Often, the uploader does not seem to be included in the swarm, or the uploader is not shown on Deluge because of the bug itself. Download and upload start and performance is (of course) terrible.

    There are no other trackers that seem affected by the issue.

    Pausing and resuming a torrent mid-race "fixes" the issue. From 2-5 peers, Deluge starts seeing the entire swarm. Most of which are finished already. Download goes to the max, upload is almost none as most of them are at 100% already.

    A catch: the issue happens most of the times, but not all the times.

    Downgrading to libtorrent 1.0.11.0 fixes the issue completely.

    Somebody on Reddit suggested disabling UTP, but it does not solve the issue.

  • Simultaneously announcing IPv4 and IPv6 addresses

    Simultaneously announcing IPv4 and IPv6 addresses

    Please provide the following information

    libtorrent version (or branch):

    1.1.4

    platform/architecture:

    Debian Stretch x86-64 (Deluge)

    compiler and compiler version:

    Those used by the debian package / pre-compiled binaries for Ubuntu

    please describe what symptom you see, what you would expect to see instead and how to reproduce it:

    After postponing the update to 1.x as long as possible (0.16.18 on Debian Jessie works fine) but now Debian stable having reached 1.1.1 with the issue still in place, I hope it can be solved. The issue seems similar to https://github.com/arvidn/libtorrent/issues/219 but its resolution did not solve this one.

    I'm trying to announce both my IPv4 and IPv6 addresses to trackers which resulted in me trying the following configurations:

    • Binding to all addresses results in the client connecting to the tracker using the address it resolves to and not supplying either "ip" or "ipv6" parameters. If the tracker resolves to an v4 address, it only receives my IPv4 address and the same with IPv6.

    • Binding to only IPv4 results in the same outcome except the tracker will obviously only see my IPv4 address.

    • Binding to only IPv6 results in the client appending the "ipv6" parameter and the tracker receiving only the IPv6 address (two times).

    • When binding to all addresses it's possible to use announce_ip which seems to work for both v4 and v6 according to NexusPHP. If one guesses the address family the tracker resolves to (or just forces it using /etc/hosts), it's possible to add the "missing" other address that way. This seems to be the only way to currently pass both v4 and v6 to it while also listening to both addresses.

    To be sure the culprit are not these conditions: https://github.com/arvidn/libtorrent/pull/597/files#diff-19929347e18a6ff1fc37f09ec720306bR3147 I compiled 1.1.4 without them without any change.

    A bit off-topic but I don't understand the reason for the latter condition. In a regular scenario I'd want to connect to as many peers as possible, private torrent or not. This obviously includes peers having only an IPv6 address (which at some point in the future will be the whole swarm).

  • Error state on unregistered torrents not set correctly (tracker_backoff and autodl)

    Error state on unregistered torrents not set correctly (tracker_backoff and autodl)

    Hey there,

    I've been trying to get Deluge 1.3.12 + Libtorrent 1.0.7 to work in conjunction with an autodl filter and a watch folder from a private tracker. I've been running around in circles trying to figure out why if when a torrent is added before the tracker has registered it, the client will wait a full 30 minutes until the next announce to refresh.

    I found the tracker_backoff setting and was hopeful that this would fix my problem; however, no amount of changing this value would do anything to solve my problem with unregistered torrents. The torrent gets added and if the torrent is not registered, the announce interval is set to 30 minutes.

    I started wondering, perhaps a failure isn't being reported properly somehow. Sure enough, I altered the tracker URL to something bogus and suddenly the retry intervals were set according to the tracker_backoff setting ( 7, 15, 27, 45, 95, 127, 165 seconds, etc). This leads me to believe that somehow the error status on unregistered torrents isn't being recognized properly, even though the Announce Status reads: Error: (Unregistered Torrent) and as a result of being able to connect to the tracker, libtorrent decides to announce as if all is normal and set the next refresh to 30 minutes.

    This may be a tracker specific issue; however, it's worth noting that the error state is read correctly when using AutoDL with rtorrent.

  • CMake: refactor scripts

    CMake: refactor scripts

    • refactor macros and create a common interface target
    • Enquote non-list variables
    • Specify project version directly in the build script instead of reading from version.hpp.
    • correctly specify boost components and minimum required version.
    • make all feature setup explicit, not automatic upon finding/not finding certain dependencies/components.
    • get rid of ucm_flags.cmake and associated manual manipulation of CMAKE_CXX_* variable manipulation
    • fix install-time warnings about CMP0007 and CMP0053
    • use only target_* commands to propagate build and usage requirements, don't use any directory-scope commands.
    • simplify feature selection
    • make use of generator expressions to help better structure the main build script. The main build script is now roughly structured as follows:
      1. feature declaration/setup
      2. find required dependency packages
      3. main target configuration: add_library(...) followed by target_*(...) commands to configure its compile features, options, definitions, etc. We strive to call each target_*(...) command only once or as few times as possible, so that each logical property of the build (compile options, compile definitions, ...) can be contained in a single place, hopefully making things easier to find and thus the build script easier to maintain.
      4. optional build of bindings
      5. install configuration
      6. optional build of tools, examples, and tests

    Pretty substantial overhaul. The focus was on modernizing and structuring it more logically and consistently.

    Tested on Windows (x64-windows and x64-windows-static with vcpkg) and Ubuntu (dynamic build). Let's see if the CI complains...

    Porting this to other branches is almost certainly non-trivial, but I'd be willing to help with that of course.

    Feel free to ask about the reasoning for each of the changes.

    EDIT: here is the old vs new dependency graph, as generated on Ubuntu 20.04 with CMake's --graphviz option, in a build with both tools and examples.

    The biggest difference is that now the dependency on Boost components is correctly acknowledged (because we're explicitly linking its targets instead of "throwing in a bunch of include files").

    The other big difference is that every target has a private dependency on the interface library libtorrent_common_cfg. This is so that targets of the libtorrent project can use some common options, without propagating to other upstream projects.

    old_graph new_graph

    EDIT: current revised target dependency graphs after changes made with the feedback below with/without deprecated functions disabled, respectively. new2 new2depr

  • Is there any way to generate torrent file from HDFS or  other non-local storage ?

    Is there any way to generate torrent file from HDFS or other non-local storage ?

    Please provide the following information

    libtorrent version (or branch): 1.2.17

    language: python/java

    hello,masters, As the title suggests, If We already have many files stored on external storage, Is there any way to generate torrent file from HDFS or other non-local storage directly? (without download all the files)

  • Use `std::chrono::system_clock` instead of `std::chrono::high_resolution_clock`

    Use `std::chrono::system_clock` instead of `std::chrono::high_resolution_clock`

    https://github.com/arvidn/libtorrent/blob/3891cd35c8a701754a075f444efd0fe8d78b4d30/include/libtorrent/time.hpp#L52

    Usage of high_resolution_clock actually lead to major confusion, it has implementation-dependent behavior. It counts time since unix epoch in Linux (stdc++ impl), but since boot in Windows. system_clock otherwise always has strict unix epoch behavior by C++20 spec.

    Ref issues: https://github.com/qbittorrent/qBittorrent/issues/13150 https://github.com/qbittorrent/qBittorrent/pull/14815#issuecomment-824000122 https://github.com/qbittorrent/qBittorrent/issues/8396 https://github.com/qbittorrent/qBittorrent/issues/8021 https://github.com/qbittorrent/qBittorrent/issues/7461

    More details: https://stackoverflow.com/questions/68906605/c-stdchronohigh-resolution-clock-time-since-epoch-returns-too-small-number/68907126#68907126

    https://github.com/Iyengar111/NanoLog/issues/11#issuecomment-275015072

  • Support for IPv6 peer connections with socks5 proxy

    Support for IPv6 peer connections with socks5 proxy

    Please provide the following information

    libtorrent version (or branch): 2.0.8

    platform/architecture: Ubuntu 20.04 LTS

    compiler and compiler version: cmake version 3.16.3 gcc version 12.2.1

    please describe what symptom you see, what you would expect to see instead and how to reproduce it.

    The socks proxy implementation does not work properly with IPv6 peer connection. This issue happens because libtorrent creates only one socket with default ipv4 endpoint 0.0.0.0 to listen all peers whenever a proxy was enabled. Here is the description from the libtorrent website

    when using a proxy, this is the hostname where the proxy is running see proxy_type. Note that when using a proxy, the settings_pack::listen_interfaces setting is overridden and only a single interface is created, just to contact the proxy.

    This setting would cause the users unable to connect to ipv6 peers since the session_impl::bind_outgoing_socket function checks if local_endpoint and remote_address belong to the same address family and otherwise fails to bind the outgoing socket to the remote address. if (is_v4(ls->local_endpoint) != remote_address.is_v4()) continue;

    To solve this issue, I find that we can modify the logic in the session_impl:reopen_listen_sockets function to let it push two endpoints v4.any() and v6.any() instead of only v4.any() into eps like this way

              listen_endpoint_t ep_v4(address_v4::any(), port, {}, transport::plaintext, listen_socket_t::proxy);
    	  listen_endpoint_t ep_v6(address_v6::any(), port, {}, transport::plaintext, listen_socket_t::proxy);
    	  eps.emplace_back(ep_v4);
              eps.emplace_back(ep_v6);
    

    I'm not sure if this modification has any unexpected side effects but this recompiled version works pretty well on my machine so far.

  • Location of *.parts files

    Location of *.parts files

    https://github.com/qbittorrent/qBittorrent/issues/13205 As I can see in this comment there is no way to define folder for parts file. Also I searched and didn't find issue about this question. So, is there in plans to provide possibility to change location of *.parts file (instead near downloaded torrent files)?

    libtorrent version (or branch): qBittorrent 4.4.5

    platform/architecture: Windows 10x64 21H1

libTorrent BitTorrent library

LibTorrent Copyright (C) 2005-2014, Jari Sundell LICENSE GNU GPL, see COPYING. "libtorrent/src/utils/sha_fast.{cc,h}" is originally from the Mozil

Nov 5, 2022
Tool for inspecting, creating and editing BitTorrent metafiles.
Tool for inspecting, creating and editing BitTorrent metafiles.

A commandline tool for creating, inspecting and modifying bittorrent metafiles.

Nov 21, 2022
Transmission is a fast, easy, and free BitTorrent client.

Official Transmission BitTorrent client repository

Nov 23, 2022
Transmission is a fast, easy, and free BitTorrent client

About Transmission is a fast, easy, and free BitTorrent client. It comes in several flavors: A native Mac OS X GUI application GTK+ and Qt GUI applica

Nov 27, 2022
qBittorrent - A BitTorrent client in Qt

qBittorrent - A BitTorrent client in Qt Description: qBittorrent is a bittorrent client programmed in C++ / Qt that uses libtorrent (sometimes called

Nov 22, 2022
Rule Engine (RE) creates an interpretable anomaly classifier from many one-feature and two-feature decision rules

Rule Engine (RE) creates an interpretable anomaly classifier from many one-feature and two-feature decision rules

Aug 15, 2022
BitTorrent DHT library

The files dht.c and dht.h implement the variant of the Kademlia Distributed Hash Table (DHT) used in the Bittorrent network (``mainline'' variant). T

Nov 17, 2022
libTorrent BitTorrent library

LibTorrent Copyright (C) 2005-2014, Jari Sundell LICENSE GNU GPL, see COPYING. "libtorrent/src/utils/sha_fast.{cc,h}" is originally from the Mozil

Nov 5, 2022
Tool for inspecting, creating and editing BitTorrent metafiles.
Tool for inspecting, creating and editing BitTorrent metafiles.

A commandline tool for creating, inspecting and modifying bittorrent metafiles.

Nov 21, 2022
A bittorrent plugin for VLC.

vlc-bittorrent (Bittorrent plugin for VLC) What is this? With vlc-bittorrent, you can open a .torrent file or magnet link with VLC and stream any medi

Nov 15, 2022
Transmission is a fast, easy, and free BitTorrent client.

Official Transmission BitTorrent client repository

Nov 23, 2022
This is a collection of tools for creating and manipulating BitTorrent v2 torrent files

torrent tools This is a collection of tools for creating and manipulating BitTorrent v2 torrent files. torrent-new can create hybrid torrents, but the

Nov 12, 2022
Transmission is a fast, easy, and free BitTorrent client

About Transmission is a fast, easy, and free BitTorrent client. It comes in several flavors: A native Mac OS X GUI application GTK+ and Qt GUI applica

Nov 27, 2022
qBittorrent - A BitTorrent client in Qt

qBittorrent - A BitTorrent client in Qt Description: qBittorrent is a bittorrent client programmed in C++ / Qt that uses libtorrent (sometimes called

Nov 22, 2022
hessian2-codec it is a complete C++ implementation of hessian2 spec

hessian2-codec is a C++ library from Alibaba for hessian2 codec. It is a complete C++ implementation of hessian2 spec. Because it was originally intended to implement the Dubbo Filter of Envoy, it did not provide good support for serialization of user-defined types (there is only one way to implement user-defined types using ADL, but it is not very complete and does not support nested types well). At the moment it is simply deserializing content into some C++ intermediate types.

Nov 15, 2022
A lightweight but complete ECS implementation for modern C++.
A lightweight but complete ECS implementation for modern C++.

ECS A lightweight but complete ECS implementation for modern C++. Features Cache friendly design implemented on top of an EnTT-like sparse set. Clean,

Sep 3, 2022
Unofficial third-party implementation of FFD (fast feature detector) published in IEEE TIP 2020.

fast_feature_detector Unofficial third-party implementation of FFD (fast feature detector) published in IEEE TIP 2020. Caution I have not got any perm

Feb 17, 2022
Implementation of Sift feature detection and matching in C + +
Implementation of Sift feature detection and matching in C + +

Sift-In-CPP This is SIFT feature detection and matching implemented in C + + Environment version information: VS2017、Opencv3.4.3 Reference link: 1.htt

Nov 19, 2021
In DFS-BFS Implementation In One Program Using Switch Case I am Using an Simple And Efficient Code of DFS-BFS Implementation.
In DFS-BFS Implementation In One Program Using Switch Case I am Using an Simple And Efficient Code of DFS-BFS Implementation.

DFS-BFS Implementation-In-One-Program-Using-Switch-Case-in-C Keywords : Depth First Search(DFS), Breadth First Search(BFS) In Depth First Search(DFS),

Nov 17, 2021
LineaMeteoStazione is a complete weather station

LineaMeteoStazione is a complete weather station which can be interfaced with professional sensors from Sensirion as well as some Davis Instrument component (Rain Gauge, Anemometer) The project is aimed as DIY weather station but just requiring the assembly part, because the boards will already be given programmed by me as well as the complete PCB. The code will be shared Opensource for the people who wants to try to do it from the beginning or modify it!

Aug 18, 2021