Network API

[NiLSPACE]

Hello,

I saw you guys are using the webadmin from Cuberite even though Cuberite has a network API. Was there a reason to choose the webadmin over that?

The documentation for it is here: http://apidocs.cuberite.org/cNetwork.html

[aduermael]

@NiLSPACE Oh this should be way better. We didn't notice that when we started Dockercraft (back in June). We should definitely use the network API instead of webadmin.

[NiLSPACE]

I believe it was implemented somewhere in January. It's possible you guys saw an old post on the forum where people asked for a network API.

[aduermael]

@NiLSPACE Maybe... anyway this is great news! Let's get rid of this weird webadmin usage! :)

[aduermael]

I started to work on some implementation using cNetwork plugin. It's going to clean the code a lot! :)

[aduermael]

@gdevillele @dave-tucker Just so you know, I'm still working on this one. Implementation should be ok on Dockercraft side. But I still have issues with the TCP connection, and it seems to be due to cNetwork issues... For example, reading in TCP connection is not blocking, cNetwork plugin answers with empty byte arrays when there's nothing to answer. And at some point I get broken pipe errors when go proxy tries to write data.

[NiLSPACE]

You might want to report that at Cuberite. The network API isn't used allot, so we don't have allot of bug reports for it. Currently I think the only places where it is used is here and here

[aduermael]

@NiLSPACE Yes, I'm investigating. I wanna be sure it's not because of one of my own mistakes. But I'll report issues to Cuberite and help fixing them as much as I can! Thanks for the links!

[madmaxoft]

Note that the network API is designed to be non-blocking - Cuberite plugins cannot afford to block for IO, because they hold a mutex to the entire world. You'll need to design the protocol to be async-aware. Usually we do that by caching the received responses until they contain enough data to be parsed as a chunk; then process the data and keep the rest in the incoming buffer, etc.

I'm still wondering, with the cNetwork API, is the go proxy still necessary? Shouldn't the plugin itself be capable of doing all the communication on its own?

[aduermael]

@madmaxoft Yes I understand all Cuberite plugins have to be non-blocking.
Also yes, theoretically we could implement everything in the Cuberite Docker plugin and get rid of the go proxy. But we have a bunch of very useful and powerful libraries all written in Go to consume Docker features, it would be really hard to re-implement that in Lua/C++... (compose, machine, networking...etc)

[NiLSPACE]

There is also a higher level client you can use: https://api.cuberite.org/cUrlClient.html