1. Welcome to LilyPad. Download the project, explore the forums, and create your own LilyPad network.

    If you use the software and enjoy it or have a question, or would like to contribute to the future of the software directly or through resources, please sign up and join our little community.

"Fulfillment" API

Discussion in 'Developer Ramblings' started by Coelho, Dec 15, 2013.

  1. Coelho

    Coelho Software Engineer Staff Member Administrator Maintainer

    Key parts of LilyPad's design is it's ability to act like a cluster, seamlessly linking multiple servers together through a distributed network. With this in mind, key aspects of the server, such as the Connect server and Proxy are expected to behave in a distributed manner, not allowing us to have plugins on them which change their behavior.

    Due to the above, plugins like the following are currently impossible without editing LilyPad's internal code:
    • Proxy which randomizes or edits the MOTD at runtime.
    • The ability to intercept player's connections (for example kick before a server connection is initiated) proxy-level.
    • Re-route a player's connection to a different server for a load balancing effect without the creation of multiple proxies.
    It is our goal to fill these gaps without breaking our distributed nature.

    Events are currently response-less within the Connect API, not allowing an event to be called and a result to be given as is in the Bukkit API (for example). We would like to keep this behavior, and we do not believe we should spend extra overhead on events that needn't have a result.

    We will with this said implement a "Fulfillment" API where one server requests (with the Connect API) that an action is fulfilled, and a response is expected. An example:

    We would like to customize our status messages so they show the player's username (in the MOTD) based on a cached representation within our database. For this, we register a hook on the Connect API for the action "status".

    Now, whenever the proxy requests that the hook "status" be fulfilled, we receive an object along with information about the user (his IP address for example), and we modify the output. The Connect API will then send your response to the Connect server, which will relay it to the Proxy (who requested the fulfillment) and then will be displayed to the client.
    Issues with this approach:
    1. Latency is an issue. If all of the machines on LilyPad's network are running on the same network (like they should) however, we are relieved of this.
    2. We need a dynamic way to encapsulate the data we're receiving so it is object oriented. For example, a status request would be a "StatusFulfillment." I was thinking of using GSON to accomplish this, and then pulling the class we convert to from the function with the @ConnectFulfiller annotation.
    3. If nothing is listening for the hook (regarding the Proxy's status), the Connect Server would still be contacted regarding fulfilling the request, even though there is no work to be done. It is best to make a cache to relieve this issue.
    4. Fulfillment is a terrible word for this. If anyone could find a better word they will receive a boat load of praise.
    Please post your opinions. Thank you.
    • Like Like x 1
  2. Coelho

    Coelho Software Engineer Staff Member Administrator Maintainer

    Code examples as follows:

    The model of the class which is to be fulfilled. This class (as it's pretty common) will likely be directly implemented in the core, but others will be able to make their own fulfillments if they wish
    Code (java):

    public class StatusFulfillment extends Fulfillment { // should we extend anything? is there a need.
       private String motd; // for example
       public void setMotd(String motd) {
          this.motd = motd;
       public String getMotd() {
          return this.motd;
    The server which responds to fulfillment:
    Code (java):

    public class Fulfiller {
       public Fulfiller(Connect connect) {
       public void fulfillStatus(StatusFulfillment status) {
    The server which requests fulfillment:
    Code (java):

    Connect connect = ...;
    String defaultMotd = "blah";
    StatusFulfillment status = new StatusFulfillment(defaultMotd);
    status = connect.fulfill(status).await();
    System.out.println(status.getMotd()); // "other"
    Last edited by a moderator: Dec 25, 2013
  3. boboman13

    boboman13 Member Contributor

    What about a more heavily implemented event API? With events for playerPings, I think there is already a playerSend, packetEvent?
  4. Coelho

    Coelho Software Engineer Staff Member Administrator Maintainer

    And to clarify, the only events available to Bukkit servers is the Message event.
  5. Tzeentchful

    Tzeentchful Member Contributor

    I think that it's a good idea. And a better name could be: "Conforment API". It's the only thing I can think of right now.
  6. Bas

    Bas New Member

    Woo, Been waiting for this, And hi again Tzeentchful haha.
  7. The_Zip

    The_Zip Active Member Resource Contributor

    Would this be just for Go? Or would will you be putting the library in JLily also?
  8. Coelho

    Coelho Software Engineer Staff Member Administrator Maintainer

    It is part of Client-Connect-API, and will only be handled by new releases of GoLilyPad.

    JLilyPad is obsolete. You should not be using it.
  9. The_Zip

    The_Zip Active Member Resource Contributor

    I wouldn't personally using it; and I am not 100 percent sure, but I am pretty sure that there is still a huge group of users that still use it. But, I do believe that when people start developing, that more people will switch over.

    I guess it comes down than to the Multicraft users that use JLilyPad. Unless someone makes some sort of tutorial on it, which I might look into tomorrow, if I get the chance. Don't really know where to start.
  10. Coelho

    Coelho Software Engineer Staff Member Administrator Maintainer

    I'm not particularly sure what you mean by that? All JLilyPad resources work 100% with GoLilyPad.
  11. The_Zip

    The_Zip Active Member Resource Contributor

    Sorry for the confusions, I am trying to say that for all the users that use host's that only offer MultiCraft, the current option is to use JLilyPad. In which, when we start developing new things using the fulfillment API, these user will not be able to use any of them.

    However, I am talking to @boboman13 right now about letting me rent out a few servers for a few days so I can make a tutorial on how to do it. After that, this will no long be an issue, and JLily will not be the main option for these users, and not a better one either.
    • Agree Agree x 1
  12. dentmaged

    dentmaged New Member

    @Coelho Your code amazes me, but what about calling the API 'the serve and reply API'?
  13. Coelho

    Coelho Software Engineer Staff Member Administrator Maintainer

    Maybe a variant, but that's a much better way to look at it.

Share This Page