Code center > Darwinbots3
P2P Internet Mode
Cyberduke:
By the way as the more astute of you may have already noticed I haven’t actually thought up a solution for propagating the grid structure yet.
Edit: And of course the reason for the structure is to give the effect of distance and separation of species for evolution, since if we just randomly pluck organisms from one environment and plonk them in another, then you are just keeping everything mixed up (like you are stirring it all about)
Cyberduke:
I really need to get back to doing some proper work, but before that I found there is information about for dealing with NAT rather than just resorting to tunnelling though it, which might be worth a look when I get some time.
http://www.codeplex.com/Wiki/View.aspx?Pro...Name=SharpStunt
http://www.codeproject.com/KB/IP/upnpnattraversal.aspx
EricL:
Just FYI, I'm opposed to P2P on practical grounds. Although I loved the way Terrarium worked (P2P bot movement with a coordinating rendevuez and statistics server) the security and network tunneling issues were and are a pain in the butt. Besides, we don't need it.
The client-server semantics of DB internet mode are neither complex nor intensive. They are similar to (actually simpler than) email systems I.e. small files (or packets of data if we design and build our own protocol/server) representing teleported bots or sim data get uploaded to a server periodically and then shortly downloaded again by another client. This is neither network bandwidth intensive nor network server cpu intensive. I claim we could easily achieve scalability of 1000+ connected sims per moderately sized server machine without heroic efforts. For comparison, corporate emails servers such as Microsoft Exchange exceed this by perhaps an order of magnitude. And because unlike email systems, the occasional loss of a bot is not serious problem, were we to write our own server, we could avoid server-side persistence of bots (they would flow through memory only with the risk of bot loss in the case the server crashes) and thus we would not be bottlenecked by the I/O capacity of the server machine (a common problem in client-server systems).
For scalability beyond this, multi-tier architectures would serve well. This is how Hotmail, Google, etc. work. Note that any topologies we wanted to build (e.g. connect to a specific IM mode such as F1 or Zerobot) could be easily built on top of this.
Anyway, my $0.02.
Cyberduke:
--- Quote from: EricL ---The client-server semantics of DB internet mode are neither complex nor intensive. They are similar to (actually simpler than) email systems I.e. small files (or packets of data if we design and build our own protocol/server) representing teleported bots or sim data get uploaded to a server periodically and then shortly downloaded again by another client. This is neither network bandwidth intensive nor network server cpu intensive. I claim we could easily achieve scalability of 1000+ connected sims per moderately sized server machine without heroic efforts. For comparison, corporate emails servers such as Microsoft Exchange exceed this by perhaps an order of magnitude. And because unlike email systems, the occasional loss of a bot is not serious problem, were we to write our own server, we could avoid server-side persistence of bots (they would flow through memory only with the risk of bot loss in the case the server crashes) and thus we would not be bottlenecked by the I/O capacity of the server machine (a common problem in client-server systems).
--- End quote ---
Ok better start by saying my comfort zone would actually lay in (just as I believe you have suggested) creating a lightweight TCP/IP(socket) based client/server system where the clients would connect and register themselves with the server and then they would then offer up bots for transfer under a particular conditions (a bot wondering off the screen, or a roaming teleporter, whatever) these are removed from the simulation, uploaded to the server and the server decides who amongst the other connected clients gets to receive this new bot(the instance not just the DNA) and pushes it down to them. (the advantage here being the centralized distribution logic) But I was trying to avoid someone needing to maintain a server with uptime demands upon it. Which the decentralized unstructured P2P route rather nicely solved “in theory” along with scalability, processor load and any bandwidth issues.
And yes just to confirm, under any TCP/IP based architecture we might build I would assume the bot is going to either be serialized and then compressed (quick and dirty) or written out by a specialized routine which can then apply optimizations such as bit-packing. Either way it ends up as a small package of data that needs to be sent to a particular instance of the simulation. I wouldn’t call either the client/server or P2P based approach bandwidth or cpu intensive (I am no longer talking about the single instance multi-user simulation which I first proposed a page or two back, which of course would be)
As far as I can see the P2P route is better in all but complexity and thus development time (which I guess is your point)
I just want to create an ‘Internet Mode’ that is less random and doesn’t mix everything up in one big pot. I actually don’t even mind hosting a dedicated server if we can keep the bandwidth low.
I am less concerned about speed as I am fairly confident that with the new modular and multithreaded approach there will be negligible impact on the simulation whatever we do, and I would expect transfer times via TCP/IP to be under a few seconds even for large multibot.
Peter:
--- Quote from: Cyberduke ---As far as I can see the P2P route is better in all but development time, and complexity (which I guess is your point)
I just want to create an ‘Internet Mode’ that is less random and doesn’t mix everything up in one big pot. I actually don’t even mind hosting a dedicated server if we can keep the bandwidth low.
I am less concerned about speed as I am fairly confident that with the new modular and multithreaded approach there will be negligible impact on the simulation whatever we do, and I would expect transfer times via IP to be under a few second even for large multibot.
--- End quote ---
You can make a series of multiple 'controled' sims rather easy. With the inbound outbound teleporters you can rather easy setup multiple sims that are in a certain way connected. (one left out: other right in) Setup a VPN and you can link the different computers together rather easy.
I don't know how much bandwidth IM currently takes, but that can't be that much. So for performance it wouldn't matter that much would it.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version