TCP sockets suggestions

zaksnet commented 5 years ago

I work alot with sockets and i think that a few things i would expect are missing in Godot.

Disconnected signal: Should be emitted when the client disconnects from the server.
Message received signal: You could set a delimiter to define when a message ends and when that delimiter is reached a message received signal could be emitted whith the message data. Currently, you can only check for data received inside the mail loop (_process).
Timeout signal: Should be emited when the connection is idle for a specified time.
Socket error signal: Should be emitted when anything other than a normal socket connection close occurs.

These would be very usefull to have but before implementing them i wanted to open a discussion and see what other people think on the matter.

EDIT: I don't think i can do this directly in StreamPeerTCP class so i'm going to create a new Node SocketClient and eventually SocketServer.

EDIT: Interestingly, after researching on how to proceed with this, custom nodes seem to be the same thing as scenes (with a few insignificant differences, like hiding their children)? unless i misunderstood something.

raymoo commented 5 years ago

StreamPeerTCP has no concept of messages. In TCP the data is conceptually just one whole stream of bytes that you receive incrementally. The pieces that you receive the stream in will not always be along a message in your netcode logic. However there could be a data_received signal that is emitted when some data is received.

zaksnet commented 5 years ago

StreamPeerTCP has no concept of messages. In TCP the data is conceptually just one whole stream of bytes that you receive incrementally. The pieces that you receive the stream in will not always be along a message in your netcode logic. However there could be a data_received signal that is emitted when some data is received.

Yeap, figured that out as you can see in my edits. My approach at the moment would be to create a new build in node that does all of the above. I have already created this as a custom node and i will proceed to create an internal node if there is enough interest.

raymoo commented 5 years ago

TCP itself has no concept of messages, so I don't see what the message_received signal would do, even if you move it into a different class.

zaksnet commented 5 years ago

TCP itself has no concept of messages, so I don't see what the message_received signal would do, even if you move it into a different class.

It's pretty much like the PacketPeer class but with signals. I call "Packet" as a "Message". So when a complete message has been received (endtag reached, or null terminated reached) then a message_received signal is emitted.

raymoo commented 5 years ago

So this would be a new protocol on top of TCP? If a user wanted a message protocol over TCP couldn't they just use the websockets classes (WebSocketMultiplayerPeer has a signal for when a packet is received)?

zaksnet commented 5 years ago

So this would be a new protocol on top of TCP? If a user wanted a message protocol over TCP couldn't they just use the websockets classes (WebSocketMultiplayerPeer has a signal for when a packet is received)?

~~I don't think WebSockets can be used for anything other than HTML5 games~~. Yes, that would be a new class that introduces all of the features i mentioned. HTTPRequest is built on top of HTTPClient also to simplify file downloads (among others), that doesn't make it obsolete.

Faless commented 5 years ago

I don't see much usage for this, it's very easy to do in GDScript, having a message received signal would mean to implement a custom protocol and introduce buffering, two things that you don't usually want when using low level sockets.

I don't think WebSockets can be used for anything other than HTML5 games.

Why?

zaksnet commented 5 years ago

I don't see much usage for this, it's very easy to do in GDScript, having a message received signal would mean to implement a custom protocol and introduce buffering, two things that you don't usually want when using low level sockets.

I wouldn't say "Very" easy, at least not for a beginner. I thought it would be a bad idea to touch StreamPeerTCP also and for that reason, I'm going to build this as a separate Node (that simplifies StreamPeerTCP). Isn't WebSocket class using signals BTW? can't we do something similar with StreamPeerTCP? Even just a "data received" signal would be nice although i can't see why using buffers is a bad idea if implemented correctly.

I don't think WebSockets can be used for anything other than HTML5 games.

Why?

Perhaps i did not express my thoughts on this correctly. WebSocket client can only be used with WebSocket servers, not with TCP servers (Since its a different protocol). It is my fault, I will change the title to something more relevant.

Faless commented 5 years ago

I'm going to build this as a separate Node (that simplifies StreamPeerTCP)

Can't you do that in GDScript an publish it in the Asset library? Again, it's going to be a small script.

Isn't WebSocket class using signals BTW?

Yeah, because with the old library we needed buffering and explicit polling in any case, so at that point there was no difference in having them or not.

Even just a "data received" signal would be nice although i can't see why using buffers is a bad idea if implemented correctly.

I think this can be done as a custom node in the Asset Library.

WebSocket client can only be used with WebSocket servers, not with TCP servers (Since its a different protocol).

Of course, but that does not mean it's only for HTML5 games. Non-web applications can (and do) use websocket, since it's a good and simple message based protocol on top of TCP.

girng commented 5 years ago

this can all be done with gds already. a plugin that does this all for you (makes it easier / simpler) would be nice. for example, if you want to emit a signal when a new "message" (stream of \<user defined> bytes read) arrived, etc.

damianday commented 5 years ago

Would be nice if the TCP stream could provide a on connect/disconnect event it's fairly standard with other TCP engines out there. Although it's easy to implement ourselves it does get a bit tedious having to with every project.

Faless commented 5 years ago

@damianday note that StreamPeerTCP is not polled automatically, you must call get_status to poll it (or do read/write), so by not calling it signals will never be emitted. See #22191 for some details. Auto-polling would likely require a "networking" server in servers/, but might end leaving users that want to do threading with less control over their peers.

VitaZheltyakov commented 5 years ago

https://github.com/godotengine/godot/issues/15393 get_status - it does not work correctly

Faless commented 5 years ago

@VitaZheltyakov please stop spamming around your issues, it's useless and pretty annoying.

godotengine / godot

TCP sockets suggestions #30397