I'm starting from scratch

[EnriqueGonzalez]

Your opinion (or your experience?)

Sorry i entered late into the conversation.

1. Server has to be as stateless as possible.
   1. Websockets are stateful but http calls are stateless
   2. Keep the Websocket as slim as possible
   3. One Websocket per user is enough
   4. Once a message goes in, en-route to where it belongs
      1. Say you will have classes for each game
   5. Don't refresh the page everytime the user navigates
      1. @aeric already has a couple of examples with HTMX
      2. HTMX WS is worth your while.
2. For your first 5 customers
   1. One server scales well enough, vertically
   2. Always use RAM for immediate calls, Thread Safe Maps
   3. At this stage, an NVME is as good as RAM, so don't be afraid of saving to DB constantly.
3. For your first 1000 customers
   1. You may want to scale horizontally, more servers
   2. Use in RAM databases such as Redis
   3. At this point, with all that money, just hire someone

That's all i have to say for now.

 

[Erel]

Very good points!

 

[aeric]

I agree with @EnriqueGonzalez.
I think Ajax is more simpler than websocket.

Keeping the server stateless reduce its burden and allows more connections to be handled. In other word, scalability.

So far I don't have the need to implement any websocket to my B4J servers. I can't speak much but when I need to, I will also minimize the websocket that I need to use.

In these few years, I already build dozens of server app just using rest api concept. It is very quick to bootstrap a server using my project template.

Stop thinking. Start doing.

 

[peacemaker]

You may want to scale horizontally, more servers

How should it be organized, if the input server-balancer is not prepared on time in advance ?
How should be switched from single-server system to multiserver ?
It's theoretical questions, maybe to be moved into a new thread...

 

[LucaMs]

Server has to be as stateless as possible.

1. Websockets are stateful but http calls are stateless
2. Keep the Websocket as slim as possible
3. One Websocket per user is enough
4. Once a message goes in, en-route to where it belongs
   1. Say you will have classes for each game
5. Don't refresh the page everytime the user navigates
   1. @aeric already has a couple of examples with HTMX
   2. HTMX WS is worth your while.

The clients will be Android and iOS, so at least for now no html, no html pages.
The slim websocket... does not depend on me. Maybe you were referring to the class that manages the websocket; this can be more or less large, it depends on the organization/structure of everything and is the basis of my question, which evidently I did not explain well.

Of course I will have a websocket for client, but I had a different way to develop the project, compared to the initial idea, kept for a long time; I try to explain it again.

"Concept" always had:
srvr.AddWebSocket("/Test", "wshUser")
The wshUser class represents user-client. Then I would have "normal" classes depending on the type of game chosen; clsChessPlayer would be specific for the chess game and I would pass it the wshUser object, only for the main user data (an ID and little else) and for client-server communications.

"New concept", recent:
srvr.AddWebSocket("/Test/Chess", "wshChessPlayer")
srvr.AddWebSocket("/Test/BlackJack", "wshBlackJackPlayer")
After authentication, which should happen in wshUser, as above, when the user chooses a game, the client disconnects from the current websocket and creates another one, to connect to one of the paths above.

In practice, I could choose whether to have a class that generically represents a user and multiple player classes specific to each game to which I would pass the wshUser object or each player class would actually be a websocket handler with the rules for the player.


As for database access, I think I'll do it as little as possible; I'll have thread safe maps for rooms and players but I won't write to DB everything that happens in the rooms, every move of the players, the game, player and room state. I would save the player's state to DB in case of disconnection (but I will have to foresee a way to delete this if the user will not reconnect soon; probably I will do it at the end of the game).

 

[LucaMs]

The problem is that I developed (a long time ago) client and server for a single game (imperfect but working).
Only later did I think that a single game would be unattractive and I thought of developing a client-server base to manage multiple turn-based multiplayer games (a base that I will use for myself that I will give away on B4X, for a minimum donation of €800 )

 

[EnriqueGonzalez]

How should it be organized, if the input server-balancer is not prepared on time in advance ?

They way Jserver is built, its better to start dividing your server than deploying the same server multiple times and loadbalancing them. what i mean is Specialized servers.

In case of LucaMS, he could start everything in a single server and later, divide each game into different servers, if a game becomes too crowded, deploy a new server for that game. So each server doesn't have to talk with each other, only the main "lobby" server and just to pass user sessions.

Keep in mind that this is way into the future. currently with such beef servers with multicore, loads of ram and space, you could run your single b4j server for a long time.

It's theoretical questions, maybe to be moved into a new thread...

Happy to answer any related question.

The clients will be Android and iOS, so at least for now no html, no html pages.

Http calls are better, IMHO, because with WS you need to juggle desconections and these are pretty common on Mobiles.

The slim websocket... does not depend on me.

Of course it does, what i mean is, keep your Websocket class as bare as possible, use it just to en-route to the working class.

"Concept" always had:
srvr.AddWebSocket("/Test", "wshUser")

its better

"New concept", recent:
srvr.AddWebSocket("/Test/Chess", "wshChessPlayer")
srvr.AddWebSocket("/Test/BlackJack", "wshBlackJackPlayer")

bad idea, one of the main concerns with WS is to know WHERE the user is, with this method, they will be everywhere

As for database access, I think I'll do it as little as possible; I'll have thread safe maps for rooms and players but I won't write to DB everything that happens in the rooms, every move of the players, the game, player and room state. I would save the player's state to DB in case of disconnection (but I will have to foresee a way to delete this if the user will not reconnect soon; probably I will do it at the end of the game).

this is part of your business logic. Consider then that in order to grow your business you need information and DB will be your only source.

The problem is that I developed (a long time ago) client and server for a single game (imperfect but working).

Never wait until you have a perfect product to launch, you will never launch it! make it as bug free as possible launch and iterate from there.

Only later did I think that a single game would be unattractive and I thought of developing a client-server base to manage multiple turn-based multiplayer games (a base that I will use for myself that I will give away on B4X, for a minimum donation of €800 )

how would you know if you dont launch it?

Shameless plug:
i have a vps and hosting business, linux is complex and windows is expensive, you can focus on building your app instead of managing your server.

B4x Focused VPS

Hello everyone! In the past few years i have been working with many people here in the forum with a wide range of projects yet all of them have in common that they need a server, sometimes for a simple JRDC2 and other times for a full fledged Jserver implementation. Well today i am offering a...

www.b4x.com

 

[LucaMs]

Http calls are better, IMHO, because with WS you need to juggle desconections and these are pretty common on Mobiles.

Yes but I have little experience in developing web pages.
Developing a B4XPages app and a B4J server is much "simpler" for me.

 

[LucaMs]

bad idea, one of the main concerns with WS is to know WHERE the user is, with this method, they will be everywhere

As with everything, there are pros and cons.

 

[GMan]

I think that what @Sandman is trying to say is:
If you pretend to prevent all the possible problems and scenarios that some code can create you will end up like the dog spinning around trying to bite his own tail.
Of course every good developer will try to think to the majority of problems and prevent them, but nailing the perfection at the first shot it's nearly impossible.
At a certain point you should publish your creation and then wait for the users feedback.
On that you will improve, add, correct.
Seeking the perfection (only to your eyes at that moment) could lead you to an eternal do/undo/redo cycle.

I saw this in many Other Szenarios,too.
Planning and planning and planning and the More you Plan the Start of any action becomes later and later.
Sometime the jump in the water is better then thinking if there are Sharks

 

[EnriqueGonzalez]

Yes but I have little experience in developing web pages.
Developing a B4XPages app and a B4J server is much "simpler" for me.

Http calls with httpjob on b4xpages, I didn't mean to change your project to web

 

[LucaMs]

Http calls with httpjob on b4xpages, I didn't mean to change your project to web

However, I think that for a turn-based game, which is NOT chess, but "immediate" games, websocket is better.

 

[aeric]

Not sure which part you stuck with.
I may start with a very simple game.
Example a game where 2 player guessing a random number.
Once the turn base logic works, it can apply to all the turn base games.

 

[LucaMs]

Not sure which part you stuck with.
I may start with a very simple game.
Example a game where 2 player guessing a random number.
Once the turn base logic works, it can apply to all the turn base games.

I don't remember all the problems I had, since the last time I worked on the project was 3 years ago, but I remember that there were many.
Probably the most complicated thing is to develop the server and the client at the same time, which are very different, especially in the management of the websocket and the destination of the messages.

I have had a working version for years, not with just two players, but with the management of multiple rooms and in each of these multiple players.
Unfortunately, due to the way everything is structured, it is difficult, if not impossible, to modify the two projects to add more games to the only one initially planned.