problems with commands

[WiFi]

** Unknown command: 'ell'
** Unknown command: 'hois'
** Unknown command: 'hois'
** Unknown command: 'hois'
** Unknown command: 'hois'

Hi... I get a lot of these, and it causes lags and it is very annoying.  I play with JavaFibs with a Mac System Leopard

Thanks

[dorbel]

"ell" is clearly Elle McPherson and if that's who yo hois, you should stop complaining.

[maria]

the first one tell you can abbreviate with just the letter t

the whois ... you need to type the whole word including the W and cut off those end quotes

[inim]

** Unknown command: 'ell'
** Unknown command: 'hois'
** Unknown command: 'hois'
** Unknown command: 'hois'
** Unknown command: 'hois'

Hi... I get a lot of these, and it causes lags and it is very annoying.  I play with JavaFibs with a Mac System Leopard

Thanks

This is a known bug in JavaFIBS, for which there is neither a workaround nor a resolution. It happens when during login two independent threads query information for the friends list (the "hois" fragments) and in parallel execute your user commands (e.g. "tell"). If you type commands during that time, they may also be truncated (the "ell" fragments).

You can minimize the effect if you wait until your friends list has been updated after login. Infrequently this still happens in "normal" operations as well, in that case simply redo the command. It also seems to be the case that when the server itself is laggy, probability for this glitch ist increased.

We (the authors of JavaFIBS) have spent quite some time debugging this one and did not come up with an easy fix. The "hois" issue is a problem in the JF design and not easy to change.

[playBunny]

If it's always and only the first character that gets lost then perhaps a command "spellchecker" could fix the command just before it's sentto Fibs?

[sixty_something]

i don't have a clue what the JavaFibs programming issues may be, but concur with inim wholeheartedly that "You can minimize the effect if you wait until your friends list has been updated after login" .. i have a pretty big friends list and find the "hois" commands almost always occurring during the time shortly after i login .. when laggy it can indeed get particularly bad sometimes taking several minutes or more for my friends list to finish processing .. on some occasions, apparently when especially laggy, i am unable to issue commands from the command line at all until the friends list finishes .. so, i have grown accustomed to the "hois" commands and the delays associated with processing my friends list at login

[inim]

If it's always and only the first character that gets lost then perhaps a command "spellchecker" could fix the command just before it's sentto Fibs?

Of course the commands as sent by the program logic are correct and always the same Strings.

The truncation happens most likely in a race condition when the parser is used threaded (where one thread parsing "steals" chars from the other), or on the network layer / IP level where the race condition assembles wrong packets. As said I dunno.

The JF parser is one *bleep* of *bleep* and nothing is easy to fix in there. It is inherently single threaded and stateful but used multithreaded. This is where the problem comes in, and if you know about spurious race conditions, you know they are very hard to debug. JF has more of them, btw, that's what I called "fix the design / architecture". Which basically is a rewrite of half of the code. Can't do that for time and license reaasons.

[sixty_something]

great explanations, inim, for a complex programming issue .. memories of such thorny problems leave me very ambivalent about no longer being involved in serious programming .. all things considered, often simple answers to complex questions are generally best, e.g. put up with it or consider it an undocumented "feature"


Sex is not the answer. Sex is the question. 'Yes' is the answer.
-- Swami X

[inim]

great explanations, inim, for a complex programming issue

Ty 60+ . One can make a statement even a bit more general. When JF was originally written in the early 2000s, we had Java 1.3, today we more than half of a decade and 3 major releases (plus dozens of minor releases) from that.

Technical notes

Java is a threaded language, i.e. Parallelism is at the very core of its programming model. However, Java 1.3 hardly used that and did most jobs as if there was only one thing done at a time. JF hardcoded some assumptions about that behaviour into the core design. With each new release of Java since 1.3, the engine became faster and more complex. Quite a few of the dramatic speed improvements of Java 6 over 1.3 are owed to parallelism. Just think multi core CPU, Java naturally can use them without any code change. However, JF was never really redesigned to cope with increasingly parallel execution, at best there are some cludges.

Two more threading problems are:

* The list of known users is maintained in a non-threadsafe data structure. Effects of this are random crashes (of which some are kludged around, but you can't anticipate all cases) and the infamous list of players in "unknown" state. To some degree the "hois" problem is related.
* Sound didn't play anymore with Java 5 and up as the Java engine went from a single threaded sound processing to multithreaded. That one was rather easy to fix, 1.0.10 and up adapted.

Legal notes

User management and parsing/networking are too complex for easy fixes w/r to threading. A redesign is prevented by license model, in which Peter owns all rights and is unwilling to share. Actually I have written threadsafe parser code (and better board code too), but contributing the modules to JF means I lose all intellectual property rights in them. And that's something I will not do. The other way around, JF is not compatible with the GPL, so Peter couldn't use my code without opening JF as well. That's the dilemma. Peter refuses an open JavaFIBS, and I refuse my code being locked into a proprietary client.

I have currently have access to 3 parser/network layer implementations in Java:
* RepBot uses one which is pretty good, but it is not based on the CLIP but on the TELNET protocol to FIBS. This model is sufficient for RepBot, but would become a problem for a full GUI client quickly.
* JavaFIBS, which works on CLIP but has inherent design issues and of course is proprietary code
* OpenFIBS, my own clean room implementaton. That one is used by the RoboCop bot. It has has a clean design and is based on CLIP, modeled after the RepBot approach. However, it is not released in a maintainable form and is not yet feature complete. It currently doesn't handle all non-numeric CLIP codes, but those are needed to e.g. implement match play (as compared to user management and shout/tell/kibitz, which can be done with only numeric codes).

Opinion

I'm deeply convinced that only an open source model is sustainable for FIBS clients.

I've reserved the "openfibs" domains and sourceforge project setup earlier this year. What I can offer is to publish my own code on SourceForge under GPL, so others can build on it. Basically I got 40% of a JavaFIBS clone, and given the JavaFIBS situation I see no alternative to actually write a fresh client. But until next sprting, I can't spend time on an unpaid open source project, I need to earn money to pay for my backgammon addiction at times.

I'm on FIBS for ages and saw clients come and go, none of them left a codebase to build on after the original author lost interest. This is unfortunately the case for the two most frequently used FIBS clients, 3DFibs and JavaFIBS. Consider both unmaintained for all practical purposes. I've talked with both authors, and there is no way to convince them to open the code (for reasons I can not understand, but have to respect). Or think of CocoaFIBS and Delfibs. Promising in the beginning, but no longer maintained (or in the case of Delfibs open sourced).

Thx for listening to my whining, but it definitely is frustrating to be in the "FIBS coder scene". Burper cracked over it, and so much talent is wasted year by year. Sigh.

[socksey]

Thank you, inim!     I feel like I've been to class and am beginning to have a very minir understanding of the problems.     Since I previously felt I would never understand any programming problems, this is quite an accomplishment.     Keep up the good work!   

socksey



Those who do not take an interest in public affairs  are doomed to be ruled by evil men.   PLATO