We're writing a webserver in our spare time and we are now at the point where we want to explore new web features. What is the best way to do full asynchronous communication with javascripts? Can we just periodically check in javascript if we've received something? Or is this only possible if you do a XMLHttpRequest beforehand? Are there other methods?
the idea here is that the client uses the timestamp from the previous result as the since parameter for the next query. the server knows it only needs to send the records that were created after that particular time.
next you create a javascript function that performs the XMLHttpRequest and processes the results, storing and using the timestamps. you run this function with setInterval.
Name:
Anonymous2011-01-12 11:03
How about I shift my dick to the most significant bit of you're anus while you're mom is watching.
>>4
You mean polling with a timestamp? We just want to send messages from the server without a request from the client beforehand (no polling). Much like instant messaging.
>>10
WebSockets are currently removed from all browsers due to ``security''. You can use Flash though, it has something similar to WebSockets. But your flesh will rot if you use Flash for that.
What this guy wants is called ``COMET''. Check again in 10 years for more elegant solutions.
Name:
Anonymous2011-01-12 12:16
>>11
Our project will probably not go public for quite some time. Are websockets guaranteed to be included in future releases of browsers or is there some fundamental flaw in their design?
Name:
Anonymous2011-01-12 13:11
>>11 WebSockets are currently removed from all browsers due to ``security''
According to caniuse.com, it's just disabled by default. Still, could you elaborate on this supposed ``unresolved protocol-level security issue''[1]?
__________________ References:
[1]: caniuse.com
Name:
Anonymous2011-01-12 14:50
Web sockets are awesome because few browsers support them, they never support the same version, and each minor change is a version breaking one.
Or, you could not be a retard and learn how browsers actually use JavaScript. Hint, script will execute as soon as the </script> element is encountered. XMLHttpRequest is useless for this.
Basically it turns out that a fair number of proxies are written by retarded five-year old monkeys, and have significant and easily exploitable security holes that allow cache poisoning. The web socket interface happened to be a vector for these attacks.
Of course, anyone behind the proxy can still intentionally perform the attack, or you could just do the attack via Java or Flash instead, both of which are more widespread than websockets.
Fuck proxies. If you check out google tech talks you see that some proxies remove the gzip option from requests so they easily can sniff through the requests (because these script kiddies are too retarded to implement their own gzip). I don't want arab mudslimes on my website anyways. I don't see why they just enable websockets? Chinese dissidents or other oppressed people don't need web 3.0 fancy chat applications anyways. Fuck em
Name:
Anonymous2011-01-12 17:19
>>18
Didn't read through all of the PDF, but it's rather annoying how Web 2.0 is all about using shitty "technologies" like AJAX (lololol let's make one HTTP request for every character you input in the search bar) or Comet or even Flash instead of doing something that's actually a good idea because all the PHP kids will get their websights "hacked."
I moderately mad.
>>20
Didn't even read the summary apparently. The protocol was poorly designed and you should feel bad for supporting it. Fortunately, they're planning to correct it before it becomes widely deployed.
So what's the best way to go? We already cut out all PHP/Ruby/apache crap by writing our own scalable webserver. We just want interactive chatting. Which is the least crappiest? Websockets/xmlhttprequest shortpolling/xmlhttprequest polling and keeping the connection open for a long time hoping there is something to update?
>>21
The protocol was correct as written, the reccomendation is just switching to a more common HTTP mechanism, and scrambling the transmission so you can't make it look like HTTP traffic.
That is only to work around buggy proxies.