Code center > Darwinbots3
P2P Internet Mode
Cyberduke:
--- Quote from: 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.
--- End quote ---
Firstly, darn you quoted me before my edit got published!
Secondly, I am talking about the Internet Mode in DB3 which doesn’t exist yet, so there are no teleporters yet.
Thirdly, VPN? Wouldn’t really be an Internet Mode then would it?
Cyberduke:
Sorry, I probably replied rather too hastily to that,
Yes an advantage to a client/server based approach would also be that lots of people could run their own servers including on a LAN or VPN etc
And yes it would be my preference to see bots transferred between sims using the borders rather than at random too.
Numsgil:
A bit off topic, but what are you using to generate diagrams?
EricL:
--- Quote from: Cyberduke ---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...
--- End quote ---
Yup, this is how I would do it. It's basically how it works today, just using files over FTP. It's more than just bots - you have sim data to aggregate - but a lightweight server wold be pretty easy to build and slot in in place of the current FTP plumbing.
--- Quote from: Cyberduke ---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)
--- End quote ---
Push is the wrong word. I want no code on clients listening on open ports, otherwise you have NAT, firewall, proxy and security issues. The client should poll, which achieves the same thing, just with a little latency. I assume this is what you meant.
On the subject of connected sim topology and the server making routing decisions, I'm not sure I agree. We could do connection topologies today without changing the plumbing, but I would want to explore why we should. Random mixing has certain advantages.
--- Quote from: Cyberduke ---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.
--- End quote ---
I host the bulk of IM today. I would be happy to host a server or two tomorrow.
--- Quote from: Cyberduke ---I just want to create an ‘Internet Mode’ that is less random and doesn’t mix everything up in one big pot.
--- End quote ---
Make a suggestion in the suggestions forum and I'll consider putting it on the list.
--- Quote from: Cyberduke ---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.
--- End quote ---
You are assuming the thing Nums is calling DB3 is a project that will someday supplant the current code base That is a big assumption, one that is not shared by everyone. It is much easier (and more likely to happen) that I simply port the current code to VB2008 to get threads and move the code base forward from there. I have a version limping in VB2008 as we speak.
Numsgil:
--- Quote from: EricL ---... It is much easier (and more likely to happen) that I simply port the current code to VB2008 to get threads and move the code base forward from there. I have a version limping in VB2008 as we speak.
--- End quote ---
I'll believe it when I see it
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version