📅 Original date posted:2018-06-22
📝 Original message:
May be it would be reasonable to think about using of SDN
technologies, such as OpenFlow. This specification is supported by
many SW and HW NW switches. This allows you to create a NW
configuration managed by the L7 OSI application layer with NW packet
routing and transparent transformation for the sender/receiver pair.
We use this technology for building of SDN-enabled Blockchain
modelling NW environments (for ex. NWs with Quantum Cryptography) for
R&D projects of our students:
http://balchemylab.gitlab.io/
ср, 20 июн. 2018 г. в 22:07, Andy Schroder <info at andyschroder.com>:
>
> Who do you think controls the routing table for the internet? Is the internet not a mesh network?
>
> --
> Andy Schroder
>
> On June 20, 2018 2:15:19 PM EDT, Joseph Hoane via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>>
>> I root for the Lightening Network’s success, but it seems to have an inherent weakness. Since routing tables are not part of the architecture how can the sender chose the next recipient so as to effect an efficient path to the ultimate receiver? With no routing table available the next receiver's connection to the remote ultimate receiver or to the ultimate receiver’s proximate connections is unknown. Even a powerful bridge node will not know an efficient subsequent path and could send the message on in exactly the most inefficient direction. How does choosing an efficient next intermediate receiver not remain a guess, a shot in the dark?
>> I don’t think any solution to the mesh network routing problem has been found. What am I missing here? Thanks.
>>
>>
>> ________________________________
>>
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Oleg Sadov [ARCHIVE] /
npub16r…y5c89
2023-06-09 12:50:54
in reply to nevent1q…kfls
Author Public Key
npub16rkpkyakwzpuvtg6w4xnmrzhlpwtp73lkr0tgaqel0rha0va3ytsty5c89Seen on
wss://relay.nostr.bandPublished at
2023-06-09 12:50:54Event JSON
{
"id": "655a496d4a9071dca73af6dc0361f055443611f9798ef39929b84290a4a8c810",
"pubkey": "d0ec1b13b67083c62d1a754d3d8c57f85cb0fa3fb0deb47419fbc77ebd9d8917",
"created_at": 1686315054,
"kind": 1,
"tags": [
[
"e",
"a96bb7ca5b972be6dfc058a4b366c0d069b40c68cfa251acd07baa1adcfde7f0",
"",
"root"
],
[
"e",
"da57d620e2c0de005dc40a34391d6c971b7b8e05a59d10ac41a9d74298e990fc",
"",
"reply"
],
[
"p",
"1c7d4637a4686939cc8b4a759caace11bb63bafb75b73b6f57d7ba81f9bd6a6c"
]
],
"content": "📅 Original date posted:2018-06-22\n📝 Original message:\nMay be it would be reasonable to think about using of SDN\ntechnologies, such as OpenFlow. This specification is supported by\nmany SW and HW NW switches. This allows you to create a NW\nconfiguration managed by the L7 OSI application layer with NW packet\nrouting and transparent transformation for the sender/receiver pair.\nWe use this technology for building of SDN-enabled Blockchain\nmodelling NW environments (for ex. NWs with Quantum Cryptography) for\nR\u0026D projects of our students:\n\nhttp://balchemylab.gitlab.io/\n\nср, 20 июн. 2018 г. в 22:07, Andy Schroder \u003cinfo at andyschroder.com\u003e:\n\u003e\n\u003e Who do you think controls the routing table for the internet? Is the internet not a mesh network?\n\u003e\n\u003e --\n\u003e Andy Schroder\n\u003e\n\u003e On June 20, 2018 2:15:19 PM EDT, Joseph Hoane via Lightning-dev \u003clightning-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e I root for the Lightening Network’s success, but it seems to have an inherent weakness. Since routing tables are not part of the architecture how can the sender chose the next recipient so as to effect an efficient path to the ultimate receiver? With no routing table available the next receiver's connection to the remote ultimate receiver or to the ultimate receiver’s proximate connections is unknown. Even a powerful bridge node will not know an efficient subsequent path and could send the message on in exactly the most inefficient direction. How does choosing an efficient next intermediate receiver not remain a guess, a shot in the dark?\n\u003e\u003e I don’t think any solution to the mesh network routing problem has been found. What am I missing here? Thanks.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ________________________________\n\u003e\u003e\n\u003e\u003e Lightning-dev mailing list\n\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev",
"sig": "d1c00856d167b4b50d767c7066cce07f4d4f382a96a22726025434e493a3f04028ea3c2bc86de4b693d38ca99f67bb2db957b7fc1f5257c8682e674d69f9e499"
}