+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Development (https://forum.cuberite.org/forum-13.html)
+--- Thread: Network API (/thread-1700.html)
RE: Network API - xoft - 01-06-2015
Could be done, although I doubt the overall usefulness. For clients of a server that the plugin has created, the plugin can make such a list on its own (in the OnAccept() callback) and for a server created by a different plugin there's not much sense giving out those links to someone else - what, you gonna write to someone else's socket datastream??
RE: Network API - jan64 - 01-06-2015
As i said, it's not critical - but it'd be something nice to have.
RE: Network API - xoft - 01-09-2015
It's looking good. I've integrated LibEvent into MCS and I'm starting to implement the internals. I just got cNetwork::Connect() working, more or less, the test code is now capable of downloading a web page over HTTP
RE: Network API - NiLSPACE - 01-09-2015
Ooh that's awesome
RE: Network API - xoft - 01-09-2015
I've pushed the initial code to GitHub, in the LibEvent branch. Go have a look, reviewers
I had to change the API a bit, based on obstacles that I came across. We'll see about the Lua API after the C++ part is finished.
RE: Network API - xoft - 01-09-2015
As for the Lua API, I think I'll change the params around; instead of listing all the callback functions as separate parameters, I'll have the API functions take a single parameter, a table, that will contain all the callbacks in a map:
-- Callback-passing example:
local Callbacks =
{
OnConnected = function (a_Link)
...
end,
OnDataReceived = function (a_Link, a_Data)
...
end,
OnLinkDisconnected = function (a_Link)
...
end,
...
}
cNetwork:Connect("google.com", 80, Callbacks)
This is how the XML parser works, I think it's better than having a million parameters. Also it allows us to expand the API later on with new callbacks, when needed, without breaking existing plugins (much).
RE: Network API - NiLSPACE - 01-09-2015
Yeah I agree. A table is better.
RE: Network API - jan64 - 01-11-2015
Sounds good.
RE: Network API - xoft - 01-12-2015
I think I have finished one of the harder parts of all this. The API now has a server implementation that listens on both IPv4 and IPv6, where available; hopefully working even on older systems such as WinXP. The downside is that there is no longer a way to specify separate ports for IPv4 and IPv6. It might be possible to separate them again, but I'm not so sure about the usefulness of that; I think unifying the ports is a good side-effect. There will no longer be two settings for ports in the server config files (Port, PortsIPv6)
RE: Network API - NiLSPACE - 01-12-2015
I have a virtual machine with Windows XP. I can test it if you want.