GUN 0.7.9 – 15M read/sec, 15K write/sec, 2K sync/sec MIT Licensed Graph Database
That collision resolution algorithm looks like a doozie from a &quot;malicious peer&quot; point of view.<p>Updates in the past are &quot;recorded and discarded&quot;, updates in the future queue up. First, let&#x27;s see if we can run our peers out of memory with a few (billion) quick future updates. Funny thing, gzip; it&#x27;s so easy to compress highly repetitive patterns. Could also just try and spam the historical log too, could we fill the disk as well as working memory?<p>If we don&#x27;t run everything out of memory, let&#x27;s just write out a few billion updates for every state interval, and make sure it evaluates as &quot;greater than&quot; (yay, JavaScript) any real value. Those updates should preemptively overwrite every other update that comes in.<p>Do you have an operating window of less than, say, 300ms? Heaven help the poor client from Sidney who keeps trying to update a master in London. Their updates will <i>always</i> be discarded (I&#x27;m not certain, but the docs read as if this occurs even when updating a value which hasn&#x27;t been overwritten by a future state). Darn you, speed of light; why can&#x27;t you be just a little faster?<p>I guess you can only hope that your clients all decide to be honest and never change your code. Or get their state counter (or clock) too far out of sync.