Cuberite Forum
Network API - Printable Version

+- 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)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15


RE: Network API - xoft - 01-17-2015

What did the server log say about creating a second socket?


RE: Network API - NiLSPACE - 01-17-2015

It did say that he created one, but I just can't reach it.


RE: Network API - xoft - 01-18-2015

Well, duh, there was code missing for the second socket Smile
I installed WinXP mode on my Win7 laptop and tried it out, it now seems to work.


RE: Network API - NiLSPACE - 01-18-2015

That explains it Smile

So should I test it once again(tomorrow), or are we done testing for now? Wink

I tried it, and it works normaly for me on Windows XP


RE: Network API - xoft - 01-19-2015

Great. So we have a working base for the API; if @worktycho doesn't have more comments about the code, we can start actually moving the server internals to use this.


RE: Network API - worktycho - 01-19-2015

I don't have any other issues with the code. I think we should start moving over as soon as possible.


RE: Network API - xoft - 01-21-2015

I'd like to change the connection-accepting code, so that the link callbacks that are given to the new link are received from the cNetwork::cListenCallbacks::OnAccepted() callback, rather than given to the cNetwork::Listen() function. Without this, it would become too cumbersome to actually use the cNetwork API in the server (binding the connections to clients would require several helper classes).

Unfortunately this means that the OnAccepted() callback will not be able to receive a cTCPLink instance, because the instance needs those callbacks to be created. If this proves to be a problem, we can add a second callback, OnLinkCreated() that will be called right after the link is created for the new connection.
Or maybe keep the OnAccept() callback as is, but add an OnIncomingConnection() callback that is called first to obtain the link callbacks:
class cNetwork
{
	...
	class cListenCallbacks
	{
	public:
		/** Called when the TCP server created with Listen() receives a new incoming connection.
		Returns the link callbacks that the server should use for the newly created link.
		If a nullptr is returned, the connection is dropped immediately;
		otherwise a new cTCPLink instance is created and OnAccepted() is called. */
		virtual cTCPLink::cCallbacksPtr OnIncomingConnection(const AString & a_RemoteIPAddress) = 0;

		/** Called when the TCP server created with Listen() creates a new link for an incoming connection.
		Provides the newly created Link that can be used for communication.
		Called right after a successful OnIncomingConnection(). */
		virtual void OnAccepted(cTCPLink & a_Link) = 0;

		...



RE: Network API - xoft - 01-21-2015

I guess no comment means no-one's against this, so I'll do it.


RE: Network API - NiLSPACE - 01-21-2015

Exacly Smile


RE: Network API - NiLSPACE - 01-23-2015

If we're having an network API for lua, then it might be usefull for plugins to be able to compress/decompress strings. Maybe we can create a zlib API?