n_nelson@dslextreme.com wrote: > I am compiling my responses to your several messages this morning here. Ok. > > Can I have the "FileLoc.log" and "Database_IO.log" files as well then? > > I ran the new version before reading this but will try to remember to do > this in future. The run this morning did not get the error window. Yes, the problem was in the fact that the "FileList.txt" had no CrLf at the end, causing the append to append to the last line, not a new one, which then created an illegal entry causing the problem. However, lately I have sent you an extra "FileList.txt", which did not contain the bug, causing your program to run nicely. The "FileLoc.log" file tells you what has FileLoc done, what entries were tested, what data was found in them and what were the results, while the "Database_IO.log" file tells you exactly what were the operations preformed on the databanks, what was the input and what were the results. > Thank you for the log file for the bug. I expect that what I need to do > is throw a large variety of activity against the ICSA over an extended > period and iron out any bugs that develop. Ok. > Your distributive processing plan was very impressive. I have written something down on this aspect. You must understand that I was working on this while in the first stages of devoloping the Console. First of all, the common idea of this distributive processing is that you have an interface fixed on the specific machine and address and a floating core. According to the nature of the ICSA, you would have the interface make very light contact with a new user, determine which floating core on what computer has the least load and direct that user to that core's address. This of course means that an interface might as well direct a user to it's own core. The interfaces would require to share information about how much load is there on each core and have an algorthm that will tell what core to use. Simulations have prooven that the best method is to have the cores send UDP load % updates to the interfaces and the interfaces then use a random pool, where the core with the least load has the most entries in that pool and the core with the most load no entries at all. Each time the interface recieves a connect request (to the ici_server), it picks one random entry from the pool and send the connecting user to the core on the address held within that entry. [The attached simulation shows exactly how such a system handles the load. By dragging the "interface" scrollbar to the right, you will increase the number of requests, the squares below tell how much load is on any specific floating core, by holding the mouse over the "X", you will get two numbers, the first about the current load and the second about the computer's speed.] The floating cores then of course require to share any other information, so it does not matter to the users to what core does one get connected to, this is what you'll know more of than me. > That e-mail > was directed at Harold who seems to thinking about his version of an > Internet parallel computer in writing of his e-mail messaging and > activity accounting. I was trying to put all that in perspective. That > is, he seemed to want to boost the priority of the Internet parallel > computer tasks. But while I think that is an important area, I am not sure > it can be quickly sold unless he has a particular company and project in > mind. He was previously mentioning an Insurance company he though might be > interested. > > You seem to have a good handle on Harold's deal request. This part is very important. I recieved a call from Harold yesterday, where he more precisely explained his intentions (you know he is not good at typing and spelling). We are now at the stage where the software copyrights need to move to address the company instead of the individual programers. As long as you're seeing Harold as someone who is likely to run off with your software, it is logical for Harold to think you are somebody not willing to cooperate to the extent where you work for a company, not for yourself. The point of Harold's e-mail orientation is in the fact that his PowerBasic enables him to use e-mail services very easily. In this aspect, he is looking to do things on his own, which is _not_ what he intends to do unless forced into by the 'fact' that you are not willing to work for a common company. Of course, I understand that this was probably nothing more than a missunderstanding, I ask you to please let Harold manage the economical part of this project, as he is the only one in the team who actualy has professional input on this subject. I know you have some extra ideas on what to do with your software, that's fine, it can be sorted out and agreed upon, but first comes first. Ok? > Yes, I need to start that project. I will likely need to provide a good > argument as to why we are not currently open-source. I have been thinking > about it. The sales items I have been thinking of are: > > Our interfaces are open and the software could be used by open-source > people to their great benefit. That is they would not need to write the > portions we already have running. They would be able to use the dynamic IP > server. They would have an encrypted messaging system in the US that > seems to be a common interest. I would be looking to make my code > open-source after a period of time and could open-source some portions > fairly quickly. The 3 You understand that according to the SourceForge policy, any code once set open-source will remain so for an undefined amount of time? Tho, I have no problem with making the interfaces open-source and giving out a compiled copy of my software intended for a very specific user for a very specific amount of time. C'ya! -- Cellphone: 0038640809676 (SMS enabled) Don't feel bad about asking/telling me anything, I will always gladly reply. Digging for info? Try AI Meta Search: Http://WWW.AIMetaSearch.Com MesonAI -- If nobody else wants to do it, why shouldn't we?(TM) Http://WWW.MesonAI.Com