tag:blogger.com,1999:blog-35492677.post9079216656673672073..comments2023-10-28T12:09:19.033+01:00Comments on Ian Hickman on Software, Technology and Leadership: Stream Computing with AJAX (Part 3)Anonymoushttp://www.blogger.com/profile/07872089265050866969noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-35492677.post-48174475648013290262007-06-13T20:43:00.000+01:002007-06-13T20:43:00.000+01:00I like the idea of verifying the solutions with th...I like the idea of verifying the solutions with the server, however I'm concerned that many problems would take too long to verify on a server.<BR/><BR/>For example one step in a complex simulation could only be verified by re-running that step.<BR/><BR/>I like the redundancy idea of sending packets to different users.<BR/><BR/>The Javascript locking out the browser could be an issue, I guess I'll have to keep the packets to be processed small.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-35492677.post-78656085441563029042007-06-13T01:30:00.000+01:002007-06-13T01:30:00.000+01:00If you are looking for a way to prevent reverse en...If you are looking for a way to prevent reverse engineering javascript, forget about it. You can make it a little more difficult to read at best. Java or flash is maybe a better choice, but even then, a descrambler and a packet sniffer will tell anything needed to hack.<BR/><BR/>To prevent data polution, you only have to let the server verify the found solutions. Finding a solution is time consuming, not the verification.<BR/><BR/>Or send the same packets to different users, and compare the results.<BR/><BR/>To get around XMLHttp security is simple, don't use it, but use iframes instead.<BR/><BR/>A problem you didn't mention: Javascript isn't multithreaded. So as long as the script is running, the browser window is locked and using 100% processor time. <BR/><BR/>It's possible to write some sort of threading emulator, with the help of timers, but that doesn't really work for time consuming calculations.Anonymousnoreply@blogger.com