jloveless

9 ms·

61.
by jloveless 9y ago
E.g. modifications that happen in your local instances are checked against our backplane. If an asset hasn't been registered (and verified independently via our backplane) it won't be available for replication
62.
by jloveless 9y ago
You can but our backplane won't know about you local modifications. When you're client informs the backplane (on a sync) it will see that those IDs and hashes we're registered and it will instruct you client to delete them.
63.
by jloveless 9y ago
We've added this to 1.7.2 [1] That will roll into production tomorrow evening. Thanks for all the feedback HN community! [1] https://github.com/edgemesh/edgemesh/releases
64.
by jloveless 9y ago
And looks like there's a docker-machine api for Vultr as well [1]. Thanks again for this! [1] https://github.com/janeczku/docker-machine-vultr
65.
by jloveless 9y ago
When you register a new asset, the Edgemesh backend downloads it from origin itself to validate the hash you've calculated. And on replication the destination recalculates it on the payload (to make sure the asset replicated correctly)
66.
by jloveless 9y ago
Totally agree - and bandwidth rates on cloud are crazy expensive [1]. The more common use-case for Supernodes are on colocated servers where you have excess capacity already - or for when you need to just deploy additional capacity for a mo
67.
by jloveless 9y ago
You can limit your supernode to your Origins [1] by setting the EM_ORIGINS environment variable. With regards the first point we should detect it (based on you ASN, if you are on 3g modems they won't be able to upload). E.g. even thoug
68.
by jloveless 9y ago
Aside from the connection API - What we do it we have a mapping of ASNs that are flagged as metered. When your client comes online we take the IP, map to the ASN and determine if it is able to upload (e.g. on cellular/metered etc). We
69.
by jloveless 9y ago
What we do it we have a mapping of ASNs that are flagged as metered. When your client comes online we take the IP, map to the ASN and determine if it is able to upload (e.g. on cellular/metered etc). We buy this data today and you can
70.
by jloveless 9y ago
Peer5 and Streamroot.io are focused solely on video - and tap into WebRTC media functionality to scale Video on Demand etc. Both great pieces of tech. We are lower level and use Datachannels[1] to p2p replicate _almost_ all assets (images,
71.
by jloveless 9y ago
I like the idea of a browser level feature for opt in to WebRTC (on a per Origin basis) - and it was proposed circa 2011 web WebRTC was coming of age. It's probably worth revisiting that discussion. Also with regards to detecting meter
72.
by jloveless 9y ago
Thank you! We work _really_ hard to ensure we're staying off CPU, managing disk, and making every replication event count (generally intra-ASN). But it's also really valuable for our NGO clients (and other non profits). My persona
73.
by jloveless 9y ago
It also has to match on the OriginID and AssetID has as well - the checksum is a final check on the actual payload (once decompressed).
74.
by jloveless 9y ago
:) You're dead right and it's why we use it inside two other top level hashes (e.g. you'd need to collide inside the OriginID space as well). It's certainly possible though (for extremely large sites) and we're expe
75.
by jloveless 9y ago
No worries - that's exactly what uBlock is there for! :) We've struggled to find the best way to add opt out on the client side without effecting the actual page itself (e.g. pop-up etc) and would love to get some thoughts on this
76.
by jloveless 9y ago
There is a 3 part hash going on. There is an Origin ID hash, a URL hash and then an MD5 on the actual payload. When a new asset is registered on the mesh the Edgemesh backplane downloads the asset direct to confirm the MD5. If it doesn&#x27
77.
by jloveless 9y ago
One option is Varnish [1] with some DNS routing to your caches. It's well tested and deployed. If most of the users are on metered connections your correct that they won't be able to provide upload capacity (but will be able to do
78.
by jloveless 9y ago
+1 this is great. Thank you!
79.
by jloveless 9y ago
Probably the best way is to check the WebRTC stats [1] if using Chrome. We sit atop the WebRTC stack for p2p functionality. [1] https://testrtc.com/find-webrtc-active-connection/
80.
by jloveless 9y ago
With this there's no DNS to even setup which is nice. Route53 is great but getting the failover and geo-routing to work is ... challenging. But I would def still keep a base NGINX and/or Varnish cache at the origin for sure. Can
81.
by jloveless 9y ago
Author and Edgemesh employee here: I think it sits pretty squarely in the 'complimentary' category. E.g. we've customers who run Fastly, Akamai , Cloudflare etc but add us as well to get increased resiliency, Real User Metri
82.
by jloveless 9y ago
Author here: >"Public cloud bandwidth is obscenely priced compared to what you can get it for on the CDN market" Amen to that! I think where this comes in to play is when you've already got colo space and excess capacity (
83.
by jloveless 9y ago
Even better! Writing deployment scripts for that. Thanks for the tip!
84.
by jloveless 9y ago
This breaks down running on a P2P CDN on Google Cloud, but the same can be done on AWS, Azure , Digital Ocean. Digital Ocean definitely has the best bandwidth rates AFAIK and has enough regions to serve as a solid backbone.
85.
Deploying a global, private CDN(blog.edgemesh.com)
114 points by jloveless 9y ago|88 comments
86.
by jloveless 9y ago
Google's network (especially w/ BBR[1]) is amazing and this makes the price point more approachable for other use cases (like running your own CDN[2]). [1] https://cloudplatform.googleblog.com/2017/07/TCP
87.
by jloveless 9y ago
This is from our (Edgemesh.com) blog about our use of Docker and how we wipe and reload every datacenter each and every night. Happy to answer any questions!
88.
Wiping the datacenters every night(blog.edgemesh.com)
1 points by jloveless 9y ago|1 comments