http://xdbe.com/blog Let Public Data Remain Public! Mon, 05 May 2008 18:56:53 +0000 hourly 1 http://wordpress.org/?v=3.0.1 http://xdbe.com/blog/updates/data-distribution-and-relay-server/#comment-3 Nick Mon, 05 May 2008 18:56:53 +0000 http://xdbe.com/blog/?p=19#comment-3 You've forgotten to mention another important reason why we actually need to have RS as an option. And this reason has more to to with the problem of uptake rather than with network efficiency as such. RS consumes very little resources, so it opens up the door for those who for whatever reason don't want or can not run a full-scale dedicated DS which unlike RS required a certain larger amount of both CPU and storage resources. Instead of being left out completely, with the introduction of RS potential participants operating servers with lower amount of hardware resources can still participate in XDBE Network thus helping to spread the data around. You’ve forgotten to mention another important reason why we actually need to have RS as an option. And this reason has more to to with the problem of uptake rather than with network efficiency as such. RS consumes very little resources, so it opens up the door for those who for whatever reason don’t want or can not run a full-scale dedicated DS which unlike RS required a certain larger amount of both CPU and storage resources. Instead of being left out completely, with the introduction of RS potential participants operating servers with lower amount of hardware resources can still participate in XDBE Network thus helping to spread the data around.

]]> http://xdbe.com/blog/updates/data-distribution-life-cycle/#comment-2 Nick Wed, 16 Apr 2008 14:48:55 +0000 http://xdbe.com/blog/?p=7#comment-2 I just feel it would be right at this stage to take the discussion back to basics, so to speak. What do we want to achieve? We need a) to keep data on all DS synced i. e. virtually identical b) to propagate new data with minimal possible delay to ALL DS c) in case of server going down temporarily establish that it is down and register which blocks of data had not been delivered to this server d) if a DS goes down for a considerable amount of time we shall mark it as DOWN and stop counting undelivered data e) if it reappears it should ask other servers for data it missed while being down starting from the last event that it has did I miss anything? I just feel it would be right at this stage to take the discussion back to basics, so to speak. What do we want to achieve? We need a) to keep data on all DS synced i. e. virtually identical b) to propagate new data with minimal possible delay to ALL DS c) in case of server going down temporarily establish that it is down and register which blocks of data had not been delivered to this server d) if a DS goes down for a considerable amount of time we shall mark it as DOWN and stop counting undelivered data e) if it reappears it should ask other servers for data it missed while being down starting from the last event that it has
did I miss anything?

]]>