core-async is extension of core project for async environments with real multithreading. It is mostly contain working with data and syncing it with UI.
Sources of networking is inside core project. You will see how really complicated it is. Networking layer are also handle cases when servers are crashing randomly and restoring everything on clients after restoring.
We reimplement low-level networking because all underlying protocols are still bad. TCP usually freezes randomly especially in mobile networks. (this is very long story and i will post something someday about this)
WebSocket (that we are actually using) are freezing too.
Good protocol is QUIC from google, but it is written on C++ (i don't like it) and quite new.
Also most of the libraries a buggy, we implement simple and time-proven solution (that was done when i worked at Telegram).
Also I can't believe in socket.io because we are able to handle 1M connections per server and no one on Node.js ever available to do this.
Thank you for sharing the code! I read through your documentation and noticed there is documentation of server-client but not server-server. How do you achieve a multi-server architecture? Is it simply to scale the Postgre database and connect more server frontend to it and load balance over those frontends? Or is there some inter server protocol as well?
Actor is built on top of Akka that have built-in support for node-to-node communication. When our CTO will wake up, he will answer in details how it works.
are you using both websocket and your new protocol ? what is the different usecases for each ?
also, did you measure power consumption on platforms like android ? one of the big problems with a lot of protocols is the impact of power consumption. I will tradeoff 5 seconds of latency if it reduces power consumption by 50% on my phone.
Actually - this is one of the questions that I have: which library should an ordinary app use to have decent power consumption performance for a messaging platform. Fast response and realtime is not a criteria. Websockets, XMPP, long polling ?
> are you using both websocket and your new protocol ? what is the different usecases for each ?
Yes. We use at lowest layers websocket and TCP just for transmitting binary frames. Our protocol is very complicated for providing stable cnnections.
> also, did you measure power consumption on platforms like android ?
This is not how cellular data works. It warms up radio before any active transmit and it lasts for much more that 5 seconds after last byte was sent. This doesn't help you at all. We have small problems in our clients with power consumption, but this is in application level, not networking.
> Actually - this is one of the questions that I have: which library should an ordinary app use to have decent power consumption performance for a messaging platform.
In all cases it depends how you use them in application level.
If you is interested in protocol, you can read docs: http://actor.readme.io/docs/protocol
Sources of networking is inside core project. You will see how really complicated it is. Networking layer are also handle cases when servers are crashing randomly and restoring everything on clients after restoring.
We reimplement low-level networking because all underlying protocols are still bad. TCP usually freezes randomly especially in mobile networks. (this is very long story and i will post something someday about this) WebSocket (that we are actually using) are freezing too.
Good protocol is QUIC from google, but it is written on C++ (i don't like it) and quite new.
Also most of the libraries a buggy, we implement simple and time-proven solution (that was done when i worked at Telegram).
Also I can't believe in socket.io because we are able to handle 1M connections per server and no one on Node.js ever available to do this.