Do we want buffering?

[jcrugzz]

Currently the setting is to drop any messages that are written to the client before it connects. This currently works for my use cases but it could be advantageous to buffer these messages to be sent in batch once the client does connect.

Thoughts?

[edef1c]

imo this is a fairly obvious footgun — things like writing startup messages immediately and such should be simple.

[jcrugzz]

@nathan7 agreed, I will make it handle those cases.

[indexzero]

-1 to generic buffering, but +1 to pre-connect buffering.

[edef1c]

Why should those have radically different semantics, @indexzero?

[indexzero]

I don't think they do. Let me rephrase: godot should never do any buffering. The "pre-connect buffering" I was referring to would be the godot instance writing immediately to a net TCP or UDP stream which (thanks to streams2 and streams3) does the buffering for us if we haven't yet connected.

[indexzero]

Yes. Going to close this. We should always write immediately which will be easily buffered by Socket instances returned from net.connect

[jcrugzz]

@indexzero i brought this up for the case of before we have created a socket but we have a godot client instance.

[indexzero]

Sockets are instantly created by node. They may not immediately connect, but their internal buffering mechanism is available immediately:

var sock = net.connect('127.0.0.1', 7731);

[jcrugzz]

Hmm, I'm thinking the godot client itself should just be a simple stream itself and auto connect when initialized to prevent the need for this

[jcrugzz]

@indexzero yes but godot.createClient(options) does not create a socket. this is the behavior I want to change.

[indexzero]

Oh yeah? Well that's definitely worth changing.

[indexzero]

Mmmmmmm ... I see the problem here. Maybe we should change the syntax from

var client = godot.createClient(options);

to

var client = godot.connect(options);

The difference in semantics here is subtle but important. Overall my goal here is to push the buffering logic onto core as much as possible.

[jcrugzz]

@indexzero yea i like it. keeps us semantically the same as core and gives an easy way to remove the connect method from the internal client prototype since we would just be constructing a client instance.

[indexzero]

I would actually say keep the connect method on the client instance. The semantic in the docs would be:

How does Buffering work in godot?

Both the server and client instances of godot do no internal buffering themselves. For connected clients buffering is performed by Node.js core net and dgram modules. Connected clients are created by calling:

var client = godot.connect(options);

Or

var client = godot.createClient(options);

I'm not opposed to dropping createClient and the connect prototype method, but we should evaluate if we want to make that kind of breaking change first.

[indexzero]

Can't edit the comment from my phone but the second code sample above should be:

var client = godot.createClient(options);
clients.connect();

[jcrugzz]

@indexzero we could technically keep it but just have it called in the constructor if we truly want to have buffering handled by the tcp socket (udp won't buffer since its not a stream). I personally say its worth it for simplicity and add it as an extra addition to v1 as we are still in dev there.

The other piece I'm thinking about is having var client = godot.connect() return an actual stream we can pipe to. This would allow us to hook in buffering for udp if we wanted or we just make it a simple streams1 stream and just have the convenience of a simple pipe. This would just make everything semantically the same which I think would be quite nice.

[indexzero]

Do we want to go so far as to implement a fully buffered WritableStream instance in godot?

[jcrugzz]

@indexzero I'm thinking yes, but at the very least it should be a streams1 stream. From a method standpoint it already meets the requirement.

[jcrugzz]

the client is the only place i see it making sense.