I recalled how sockets work in depth a bit. You should perceive socket as 'entry' or 'end' in the tunnel. It is entry or end only from perspective of they guy who goes there, if you enter the tunel, the first hole is entry, and the last one is end, but for the guy that goes opposite direction it is opposite.
So with regards to chat service in today's system design:
- on the server side there is one listening socket, that registers the client sockets and saves them in memory. Later on they will represent connection with multiple clients.
- rooms are also our app concept, and passed with the socket message.
So with regards to chat service in today's system design:
- on the server side there is one listening socket, that registers the client sockets and saves them in memory. Later on they will represent connection with multiple clients.
- rooms are also our app concept, and passed with the socket message.
β€3
The flow for the client 1:
- client connects to server socket, creating "entry" socket to the server called "`server socket 1". This socket is used to transmit data TO the server and receive data FROM the server
- server socket accepts the connection and creates client's entry socket called "`client socket 1". This socket is used to transmit data TO the client 1 and receive data FROM the client 1.
- after sockets are binded: client will send the message with userid (probably signed on for security and integrity) along with chat id (room). The server will parse it and add the client's socket to the room specified in the message. Everything is in memory at this point.
AFAIK there is NO special limitation to the number of client sockets that can be connected apart from memory, cpu, bandwidth etc. There is FileDescriptor limit, which can be extended
===
For scalability - we can just intro some level 4 LB (Transport level TCP/UDP), or as we discussed we can have some "master node" that knows about socket servers and assigns them in a clever way.
- client connects to server socket, creating "entry" socket to the server called "`server socket 1". This socket is used to transmit data TO the server and receive data FROM the server
- server socket accepts the connection and creates client's entry socket called "`client socket 1". This socket is used to transmit data TO the client 1 and receive data FROM the client 1.
- after sockets are binded: client will send the message with userid (probably signed on for security and integrity) along with chat id (room). The server will parse it and add the client's socket to the room specified in the message. Everything is in memory at this point.
AFAIK there is NO special limitation to the number of client sockets that can be connected apart from memory, cpu, bandwidth etc. There is FileDescriptor limit, which can be extended
===
For scalability - we can just intro some level 4 LB (Transport level TCP/UDP), or as we discussed we can have some "master node" that knows about socket servers and assigns them in a clever way.
β€3π1
andreyka26_se
The flow for the client 1: - client connects to server socket, creating "entry" socket to the server called "`server socket 1". This socket is used to transmit data TO the server and receive data FROM the server - server socket accepts the connection and createsβ¦
UPD: Level 4 Load balancer won't help here, as it does not have mechanism to route by payload (where chat id is located).
So only custom WebSocketServerManager and connect from client directly, or LB with app level, that can distribute by route or payload
So only custom WebSocketServerManager and connect from client directly, or LB with app level, that can distribute by route or payload
This media is not supported in your browser
VIEW IN TELEGRAM
Wtf is this sound
Sorry, guys, probably will not be able to meet with anybody as I am tight in schedule a bit. But next trip - yeah, lets go.
π2
Googlers have 3 meals per day, coffee served BY BARISTA, swimming pool, gym, etc in the office directly. This is only what I saw π
π₯2π€―2
They have no sweets as I understand. Poor company I am working for, very poor
π6