Stéphane Bortzmeyer

Alexandre Pion noticed a small bug: for the median too, we should exclude the null results.

One may assume that, if some people delayed the changes, other people rushed in to adapt the networks to the increased load? Both behaviour may explain why the change rate is more or less the same?

“Thanks, Stéphane! At some point I may add extra examples to the documentation. Is it okay if I include something based on your example?”

You're welcome to use this example as you see fit. A better version is available at https://www.bortzmeyer.org/files/ris-live.py

Here is an asynchronous version of a Python client so you can do other things while waiting for updates. (In that case, we just display a timestamp.) #!/usr/bin/env python3 PERIOD = 5 RFC3339 = '%Y-%m-%dT%H:%M:%SZ' import sys import json import time import asyncio # https://websockets.readthedocs.io/ import websockets class RISliveWebsocket(): def __init__(self, router, asn): self.router = router self.asn = asn async def __aenter__(self): self._conn = await websockets.connect("wss://ris-live.ripe.net/v1/ws/?client=asynchronous-python-script-by-me") opening = json.dumps({"type": "ris_subscribe", "data": {"host": self.router, "path": self.asn}}) await self._conn.send(opening) print("Connected, %s sent" % opening) return self async def __aexit__(self, *args, **kwargs): print("Goodbye") pass async def send(self, message): await self._conn.send(message) async def receive(self): print("Trying to receive") return await self._conn.recv() async def tick(): while True: await asyncio.sleep(PERIOD) print("Waking up, it is %s" % time.strftime(RFC3339, time.gmtime(time.time()))) async def main(router, asn): sock = RISliveWebsocket(router, asn) async with sock as feed: while True: print(await feed.receive()) if __name__ == '__main__': if len(sys.argv) != 3: print("Usage: %s RIS-router ASn" % sys.argv[0], file=sys.stderr) sys.exit(1) try: loop = asyncio.get_event_loop() loop.run_until_complete(asyncio.wait([main(sys.argv[1], sys.argv[2]), tick()])) except KeyboardInterrupt: pass # Does not call __aexit__?

“Stephane, Quad9 has also DoH ( https://www.quad9.net/doh-quad9-dns-servers/ )”

OK, they should just update the FAQ :-) Thanks for the info.

"CloudFlare, Google and Quad9 all offer DoH" As far as I know, only Cloudflare does it. Google Public DNS has an experimental DNS-over-HTTPS (proprietary, not DoH) service and Quad9 seems to have "only" DoT (see https://quad9.net/faq/#Does_Quad9_support_DNS_over_TLS )

Saying that automatic contracts ("smart contracts" is the marketing BS) cannot be changed ("these contracts are unmodifiable") is not strictly true. To quote an old saying "every problem in computer science can be solved with one more indirection". So, you can have a pointer to the current version of the code of the smart contract, and changing the code by adding a new version of the pointer. Of course, this adds complexities and security risks but it shows that there are ways to modify automatic contracts, for instance to follow a change in policies. The description of the "51 % attack" is very sketchy ("quickly spawning a large quantity of client nodes that participate in the consensus making"). In a real blockchain, techniques like proof-of-work and proof-of-stake prevent this trivial Sybil attack. But there is a subtler reason why the "51 % attack" is overhyped: it is easily detectable (the Bitcoin Core code, for instance, logs it). So, honest miners will see it. It will not be easy to recover from the attack (the honest miners will have to fork) but it cannot be stealthy.

The link "real-time streaming capabilities" goes to a 404. I suspect the correct target is https://labs.ripe.net/Members/colin_petrie/updates-to-the-ripe-ncc-routing-information-service