Queue full

Jump to navigation Jump to search

I´m writing a custom client right now (slowly writing it from scratch in the last months). Yesterday I managed to make it fully functional, although it still needs polishing (make hardcoded behaviour more configurable). I´ll make it available here after it becomes more stable.

I can add bulk upload, but it will break compatibility with the current protocol. Unless both clients and servers support 2 protocols at the same time.

Features I managed to include in this custom client so far:

- Full compatibility with the current protocol. (I hope that underscore bug was the last one)

- Multiprocess/multithread support.

- Parallel downloading of JARs. (currently hardcoded at 15 simultaneous downloads)

- Processing battles in parallel while uploading results in a separate process. (currently hardcoded at 1 simultaneous upload)

- Abusing the Java 5 concurrent API to keep the code readable in the presence of parallelism.

- Upload throttling in case of errors (currently hardcoded at 10 seconds delay after each error). It is possible to throttle uploads in the absence of errors too, although I wasn´t planning to do that.

- Smarter handling of priority battles. One big pairing matrix handles priority battles, new competitors and competitors with low battle count, all at the same time. And it is independent from iterations (which I eliminated).

- Communication between processes through the network, allowing clients spread accross a LAN. (currently hardcoded at "localhost" address and 1099 port only)

- Automatic copying of JARs between clients. If a single "server" process has all JARs, no client needs to download from internet.

- Logging support. No more System.out.println. You can configure how messages appear in the console (or in a file), adding for example, time and severity.

- Internally, battle parameters are all dynamic. Parameters like number of competitors, inactivity time, gun heat cooldown, codesize classes, hideRobotNames, are all concentrated in a configuration class. The idea is to put them all in configuration files and make divisions like twin duel, team melee or anything else fully supported.

MN (talk)18:23, 31 May 2013

Neat! Sounds like a lot of work. What's the setup like for multi-process battles? And is it the same mechanism locally vs clients across a network?

Voidious (talk)18:59, 31 May 2013

You do not have permission to edit this page, for the following reasons:

  • The action you have requested is limited to users in the group: Users.
  • You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

You can view and copy the source of this page.

Return to Thread:Talk:LiteRumble/Queue full/reply (4).

 

Yes, it is the same mechanism locally and across a network.

The overhead from RMI could be avoided locally, but it is so low I didn´t bother.

MN (talk)21:36, 31 May 2013