10
\$\begingroup\$

I am planning a King of the Hill challenge, but when looking at older ones I noticed that there appear to be a large number of techniques used for communication between the control program and the entries.

These techniques include:

  • Creating classes.
  • Arguments and stdout.
  • Stdin and stdout
  • TCP/IP

What are the pros/cons of the different methods? Which one allows for the most language-agnostic question?

\$\endgroup\$
3
  • 4
    \$\begingroup\$ This depends on the type of contest. For my Hunger Gaming, a full game could take 10k+ turns times the number of competitors. There was simply no way I could use a "process per turn" method, it would take forever. I also didn't want to do classes, since that makes the barrier for entry among the non-chosen languages much steeper. I went with STDIN/OUT simply because it's easier in general than TCP/IP. There are other options that could have worked, I'm sure, but use whatever works well for you. \$\endgroup\$
    – Geobits
    Jun 4, 2014 at 18:47
  • 2
    \$\begingroup\$ I personally like the subclassing plus providing a wrapper subclass which calls other processes. That gives you the convenience of strongly/statically typed subclassing for those who know your language but you're not excluding answers in other languages. Of course, this means more effort for you, because you need to implement both communication channels. \$\endgroup\$
    – Martin Ender
    Jun 4, 2014 at 20:00
  • \$\begingroup\$ Funny you should ask. I was thinking recently about how a generic KotH engine could be implemented which would take care of communication/scheduling/scoring. \$\endgroup\$
    – wrongu
    Jun 10, 2014 at 0:36

1 Answer 1

Reset to default
10
\$\begingroup\$

Creating Classes

This method involves asking all submissions to directly subclass an abstract class that you wrote (or, less commonly, implement an interface you wrote). The submissions are instantiated, rather than invoked.

Advantages

  • Instantiating an object, calling member functions, and getting return values (results) is relatively easy, considering that you, the author, provided the framework.
  • Compiling the final project(s) generally doesn't require downloading any extra software.
  • Requires zero parsing of input and output. You can simply pass that four dimensional array.
  • At the cost of some additional effort, can be combined with any of the other approaches, by implementing a wrapper for those as a subclass. This opens the door to submissions in other languages, but also means the OP will have to download compilers or interpreters for all of those other submissions.
  • Fastest. You don't have to constantly decode/recode data being passed to/from submissions.
  • Allows you to provide helper functions for submissions. Instead of passing the entire game state to submissions, they can simply make function calls to query it. (This is technically possible with other communication methods, but the overhead cost is pretty high)

Disadvantages

  • The challenge is limited to one language (ignoring weird languages like Scala that can inherit from class written in Java or Scala)

Command Line Arguments and STDOUT

Submissions get what they need from command line arguments, and hopefully return what they are supposed to from STDOUT.

Advantages

  • Provides a unified, easy to read, "this is how I will run you" command. For example:

     java YourProgram Arg1 Arg2 Arg3

  • Works well when you want to invoke a process and then kill it after getting results.

  • Challenge is not restricted to one language.

  • Easiest way to write a controller that communicates with multiple languages

Disadvantages

  • Requires parsing output, which also means you must have to have defined a rigorous format for output.
  • Slowest method of communication, as programs need to boot every time you want to communicate with them
  • If anybody wants to test their solution against all of the submissions, they need to install all of the languages

STDIN and STDOUT

Submissions get what they need from STDIN, and hopefully return what they are supposed to from STDOUT.

Advantages

  • Challenge is not restricted to one language.

Disadvantages

  • Requires the program to already be running and waiting for input.

  • Requires parsing input and output, which also means you must define a rigorous format for each.

  • Can be tough to kill unresponsive processes (as read() calls usually block in most languages)

  • Faster than command line args, but sending data over pipes is still significantly slower than native function calls.

  • If anybody wants to test their solution against all of the submissions, they need to install all of the languages

TCP/IP

Submissions get what they need and hopefully return what they are supposed to via TCP/IP sockets

Advantages

  • Challenge is not restricted to one language.

  • The controller can be placed on a server, and submissions can easily communicate with it.

Disadvantages

  • TCP/IP is usually more difficult to work with than STDIN and STDOUT.

  • Requires parsing input and output, which also means you must define a rigorous format for each.

  • If anybody wants to test their solution against all of the submissions, they need to install all of the languages

  • TCP/IP has a limitation on packet size (64K). Mostly you don't need this size, but in extreme cases you might need to send more data than 64K and you'll need to split the data, which will make the input/output format more complicated.

\$\endgroup\$
5
  • 1
    \$\begingroup\$ Please mark this as community wiki. My fingers got tired. \$\endgroup\$
    – Rainbolt
    Jun 4, 2014 at 20:06
  • \$\begingroup\$ Ok, converted to CW. \$\endgroup\$
    – Doorknob
    Jun 4, 2014 at 20:55
  • 1
    \$\begingroup\$ The issue of instantiation once per action vs once per contest is relevant to stdin/stdout, but not so much to classes or network comms. Is it worth splitting stdin/stdout to cover the two cases separately? \$\endgroup\$
    – Peter Taylor
    Jun 5, 2014 at 22:22
  • \$\begingroup\$ Would it make sense to split this into multiple answers, to allow users to vote and comment on each method separately? \$\endgroup\$
    – Ilmari Karonen
    Jun 16, 2014 at 18:59
  • 1
    \$\begingroup\$ @IlmariKaronen I think it depends on which question you really want to answer, "Which method is best?" or "What are the pros and cons of each method?" If kitkar2000 would ask one question instead of two, then I would be less conflicted about choosing the best method of organizing the answer(s). \$\endgroup\$
    – Rainbolt
    Jun 16, 2014 at 19:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .