How to make clients and the server live happily together

Well, I have some intent to rewrite many Graal Reborn components in Go.
Because I like Go!
So you should! :slight_smile:

Now, I still have a very fuzzy understanding of packets exchange between components.
But I don’t like too much current code.

I will try to summarize how I imagine things (in my ideal thinking world).
Oh well, not so ideal, we have to deal with current far from ideal implementations.

Anyways… Once upon a time, there was a component that wanted to export functions to other computers on the network.
So clearly, this must be a proxyOut component. Also we have zero or more components that wish to use functions exported by the ProxyOut.
Surely it must be the ProxyIn(s) component(s).

So what the proxyOut and proxyIn share, is a list of functions, also known as an interface (in Go).
Oh well, very likely, it is not exactly functions we want to export, but methods (functions attached to data structures).
Anyway, still Go interfaces.

So let’s take a simple method: player.move(int x, int y)

So we call that method… which:
Create a packet
Set packet command id (each method or functions have a different byte id that identify it)
Add an integer with x in the packet
Add an integer with y in the packet
Send the packet to the connection…

Packets are sequence of bytes.

Connection? ProxiOuts have a connection.
Eh… or maybe many connections… one for every client they are connected to.
Let’s make it simple… a proxyOut have only one connection. So there is one proxyOut for each proxyIn.

Connections handle encryption and compression.

So basically, proxyOut is the composition (stuff put together) of an interface with an output connection.
And a proxyIn of that proxyOut is the composition of the same interface with an input connection.

And now, proxyIns and proxyOuts live happily togethers.

Is it too simple?

So a GR server have one listServerProxyIn, onelistServerProxyOut, and a list of clientProxyOuts and clientProxyIns.
A GR listserver have a list of gserverProxyIn and gserverProxyOut, and a list of clientProxyOuts and clientProxyIns.
A GR client have one listServerProxyIn and one listServerProxyOut and also one gserverProxyIn and one gserverProxyOut.

Note that pairs of proxyIn and proxyOut inside a component are normally not for the same interfaces (list of functions or methods). That is because most components want to talk bi-directionaly to one an other, but for different commands in each direction.

Edit: It’s been a few days without anyone telling how bad this design is… So I guess this make this design a great success. So I expect to begin it’s implementation in the next few days or weeks.