Code center > Darwinbots3
P2P Internet Mode
Numsgil:
You mean encode the entire binary file in the url? Speaking of which is there any sort of limit on the length of a url? Like could you have a url that's thousands of characters?
goffrie:
Not quite, POST data is like GET data (which is in the URL) but it goes after the request headers. No idea how to do that in VB or C#, though.
You might be able to encode the data in the URL, but the web server would probably reject it as a buffer overflow attack, (or the server would have a buffer overflow).
Numsgil:
Now we're running in to my ignorance. Perhaps a short example?
EricL:
--- Quote from: goffrie ---It would be nice if there was a peer-to-peer network of sorts for Internet Mode...
--- End quote ---
This is exactly the way Terrarium worked. The server did nothing but act as a rendevuez service and collect stats. Bots moved between peers. I agree with you in general, but.... Not only is it a lot of work, but there are serious security issues to overcome in such an architecture depending upon the protocol and the means by which the P2P communication is acheived. Anytime you start running server code (meaning code that listens for new requests on a port and performs work based on those requests) on clients, you open up a serious security can of works not to mention isuses with NATs and firewalls, etc.
People should not confuse the client connectivity topology we choose to use with transport latency issues or with the connectivty problems inherent in the current FPT-based design. The current FTP based thing is problematic to be sure, but the connectivity problems are not inherent problems with the design. Those can be fixed by moving to a more reilable server and moving the server communication code out of proc, both of which I am working on (using in part, some code from Nums).
But we will reach scalability limits on the current architecture. Understand, there is no real server today. No server that is, other than the FTP server itself. There is no code authored by me running on any machine except the client simulators each of us run. They cooperate through the FTP server by moving files, but in an incredibly ineffecient manner becuase they are forced to shoe horn their semantics into file movements and the semantics of the FTP protocol. Some poeple call this a shared-file or file-sharing version of cleint-server. Early corporate email systems (circa 1990) such as CC:Mail and Mcirosoft Mail used this archtiecture. It is not true client-server (like POP/SMTP). Were we to move to a true client-server model where we had special code runnnig on a server, implimenting our specific semantics, we could easily scale to several thousand sims connected through a single server. Buidling this on top of HTTP or PHP or sockets or whatever is mostly a discussion of ease of implimentation. The result is the same, a true cleint-server architecture.
Scaling beyond that would require mutliple servers with connection logic or partitioning or a P2P architecuture.
Numsgil:
As a followup to my last post... There are there any problems having the download script save data to disk? If there is, is it possible to embed binary data in the HTTP the PHP script returns? If that wouldn't work either, an text based organism file would probably be possible. I know for sure that would work...
Which leaves uploading the file, which is where I don't know how to proceed.
--- Quote from: EricL ---Scaling beyond that would require mutliple servers with connection logic or partitioning or a P2P architecuture.
--- End quote ---
If we use a PHP sheme, we can leave the details of managing multiple servers to our web host. As the number of users increase, it would just change the amount of bandwidth we would need to pay for (keeping in mind that .dbo files are small and our present bandwidth is only at like 2% utilization, I don't think there's going to be a problem). If the file accesses start become a problem, it would be a simple matter to move from a file scheme to something in a database.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version