Welcome to Inkbunny...
Allowed ratings
To view member-only content, create an account. ( Hide )
Weaselgrease

Chatroom Beta Test Stream!

I'm going to be testing my new chatroom today.  Made in Java!  I've seen two minor bugs so far but nothing game-stopping.  Come help me find more!

http://weasel.jouster.us
Viewed: 39 times
Added: 5 years, 3 months ago
 
ralesk
5 years, 3 months ago
Java?  These days people have that thing disabled by their browsers for security reasons o.o  If they even have it installed.
Weaselgrease
5 years, 3 months ago
Which is sad.  The end users are blaming the language for their inability to use good security practices. ;)  The same way people who program add-ons for web browsers are the major cause of a browser being full of memory leaks.  Not the browser itself.  Flash has the same kinds of problems, but Adobe's answer is to require administrator control of the system, which is impractical for webhosting, *and* that the end user has to download seamless updates on a daily basis just to update a blacklist of defunct code/websites.  Java itself doesn't have holes, it's just a very robust language with a lot of possibilities.  
ralesk
5 years, 3 months ago
I'm not sure Mozilla's decisions to disable the plugin (as do they with some of the outdated Flash plugins — n.b. the newest Linux release doesn't even run unless you're on an nVidia system) is because people's inability of something or other.  More likely that the plugin itself has some known holes that Oracle can't be properly arsed to fix.

So far my experience with Java isn't too happy otherwise either.  Different versions are vastly incompatible with each other (and nobody seems to use 7, most stuff that require Java rely on 6), yet old ass-backwards practices from pre 1.5 era are still lingering around even today.

In any case, I find it an odd decision.  People don't tend to have Java installed these days unless they need it because of some obscure government/enterprise site (whereas the similarly messy Flash is almost ubiquitous as far as desktop browsers go)... and people (unless they browse from an enterprise environment, but I sure hope they don't go dick-watchin' from corporate networks) usually have modern enough browsers to be able to understand modern JavaScript, long polls or even WebSockets.  As much as I personally dislike JavaScript (although I have to work with it regularly), it would have been a way more sensible choice than Java :)

Although... I can understand if you actually like Java as a language.  I mean, I can't (because it's one of the messiest languages around, very close, but not quite where C++ is), but if that's what gets you going I get the idea :)
Weaselgrease
5 years, 3 months ago
Actually, it's very believable that in order to cut down on liability a provider of a product such as a web browser would by default disable features that can easily be exploited.  Every major User-friendly OS vendor does it out of the box.  And all browsers do it.  They don't give every end-user the option to make themselves susceptible to certain things.  Java is capable of a lot of things, and especially recently every Java object built into a website pops up a dialog box asking if the user wants to trust the site.  The only difference between licensed and unlicensed is a little line of red text talking about vulnerability of running unlicensed applets.  But since I can't pay $500 a year for a license, the end user just has to take my word for what it's worth that I'm not trying to install viruses on their system with my software, because I could very well do that with a Java applet.

Java 6 isn't compatible with 7, but 7 is compatible with 6 in most instances, even with a lot of deprecated constructors.  The issue there is programming explicitly for specific versions and no other.

I've tried using JavaScript to do this exact same thing.  Several times.  The most recent time I had been using an SQL database as a chat log, and then the database server got brute-forced and all the databases across multiple sites were destroyed.  Now the SQL databases don't allow more than so many concurrent connections within a set time period.  So it's a useless method of chatting for me.

Java literally is my last and only option for this without just using Livestream's chat in all of its watered down control, censoring glory, resource-diminishing AJAX requests 50 times a second, and flash-based memory leaking.  Otherwise I'll have to actually write a program for people to just download and run locally if they want to watch my streams.
ralesk
5 years, 3 months ago
Hmm..

" The most recent time I had been using an SQL database as a chat log, and then the database server got brute-forced and all the databases across multiple sites were destroyed.  Now the SQL databases don't allow more than so many concurrent connections within a set time period.


There needs to be only a few connections, those made by the server side of things, which then communicate (by whatever means) to possibly much more clients — this is no different than non-AJAX communication really, there are significantly more clients at a time than there are connections to the underlying database.  Push methods from the long poll (comet) to the more recent and standardised WebSockets alleviate the pain that is the clients banging on the RPC/API/whatchamacallit server many times a second.
Weaselgrease
5 years, 3 months ago
The chat system needs to be informed of new data.  When using Javascript, the only way to do that is to fire an AJAX request at it.  I had mine set to do that every two seconds.  Meanwhile... Livestream's chat sends 50 AJAX requests a second.  The actual video streaming client sends an AJAX request every millisecond to check for new segments of video to prebuffer.
ralesk
5 years, 3 months ago
Nope, it doesn't (traditionally, or under certain circumstances, yes, it does, but not anymore, really): https://en.wikipedia.org/wiki/Push_technology
Weaselgrease
5 years, 3 months ago
That's interesting reading!  Though I am curious, then, what it is the Livestream flash objects keep sending to the home server so many times a second.  Unless it's anonymous usage statistics.

I was actually going to try to use Flash originally, but Adobe requires that in order for a Flash object to send any kind of raw data requests to a server, the Flash object source has to come from the server it wants to talk to, and it has to be given acknowledgement from a port within the administrator bounds, AKA a port I will never have access to under any website hosting service.  That's Adobe's answer for virus injection through Flash objects.  Along with bi-daily updates to a blacklist.
ralesk
5 years, 3 months ago
" That's interesting reading!  Though I am curious, then, what it is the Livestream flash objects keep sending to the home server so many times a second.  Unless it's anonymous usage statistics.


No idea, but what you described earlier seems extremely wasteful.  Even on a proper socket I'd think 1000/s is a rate that one doesn't need on a video that has at best 15 FPS (or what was it).

As for the flash thing, not familiar with that in particular but that sounds very similar to the security measure taken by eg. JavaScript: the same origin policy.  (Which is of course pretty often broken)  
araquan
5 years, 3 months ago
Couldn't load it on some systems... it crashed my browser on another.  In all cases I did get to the "I can't verify this signature, do you want to run this?" dialog, but after that... either nothing, or a crash.
Weaselgrease
5 years, 3 months ago
I'm assuming flavors of Linux with Firefox and/or Opera?
araquan
5 years, 3 months ago
Linux: SeaMonkey and Firefox; Mac OS X: SeaMonkey.  I didn't get around to trying with Safari because moving/laundry/SLEEP/work. @_@
araquan
5 years, 3 months ago
BRIEF Safari test: nothing.  It didn't even try loading so far as I can tell.  Alas, I have to do more stuff/SLEEP/work so I can't really dig into it more tonight.
New Comment:
Move reply box to top
Log in or create an account to comment.