diff --git a/Dockerfile b/Dockerfile index 928f3d5057..cef5c88254 100644 --- a/Dockerfile +++ b/Dockerfile @@ -5,4 +5,3 @@ RUN apk --no-cache upgrade && apk --no-cache add ca-certificates COPY centrifugo /usr/local/bin/centrifugo CMD ["centrifugo"] - diff --git a/docs/content/faq.md b/docs/content/faq.md index 6ac9a124ca..d3deabba84 100644 --- a/docs/content/faq.md +++ b/docs/content/faq.md @@ -80,6 +80,10 @@ No - Centrifugo is best-effort transport. This means that if you want strongly g Centrifugo can keep message history for a while and you can want to rely on it for your needs. Centrifugo is not designed as data storage - it uses message history mostly for recovering missed messages after short client internet connection disconnects. It's not designed to be used to sync client state after being offline for a long time - this logic should be on your app backend. +### What is the difference between Centrifugo and Centrifuge + +[Centrifugo](https://github.com/centrifugal/centrifugo) is server built on top of [Centrifuge](https://github.com/centrifugal/centrifuge) library for Go language. + ### I have not found an answer on my question here: We have [gitter chat room](https://gitter.im/centrifugal/centrifugo) - welcome! diff --git a/docs/content/misc/migrate.md b/docs/content/misc/migrate.md index 7d7f4edca5..aabd61852b 100644 --- a/docs/content/misc/migrate.md +++ b/docs/content/misc/migrate.md @@ -14,7 +14,7 @@ Centrifugo v2 simplified communication with API - requests should not be signed Centrifugo v1 could process messages published in Redis queue. In v2 this possibility was removed because this technique is not good in terms of error handling and non-deterministic delay before message will be processed by Centrifugo node worker. Migrate to using HTTP or GRPC API. -### Use JWT instead of hand-crafted token +### Use JWT instead of hand-crafted connection token In Centrifugo v2 you must use JWT instead of hand-crafted tokens of v1. This means that you need to download JWT library for your language (there are plenty of them – see jwt.io) and build connection token with it. @@ -22,4 +22,7 @@ See dedicated docs chapter to see how token can be built. All connection information will be passed inside this single token string. This means you only need to pass one string to your frontend. No need to pass `user`, `timestamp`, `info` anymore. This also means that you will have less problems with escaping features of template engines - because JWT is safe base64 string. -### \ No newline at end of file +### Use JWT instead of hand-crafted signature for private subscriptions + +Read chapter about private subscriptions to find how you should now use JWT for private channel subscriptions. + diff --git a/docs/content/server/protocol.md b/docs/content/server/protocol.md index eca84d7ad2..9eec1b5c25 100644 --- a/docs/content/server/protocol.md +++ b/docs/content/server/protocol.md @@ -222,7 +222,7 @@ The tip whether or not connection must be refreshed comes in reply to `connect` When client connection expire mechanism is on the value of field `expires` in connect reply is `true`. In this case client implementation should look at `ttl` value which is seconds left until connection will be considered expired. Client must send `refresh` command after this `ttl` seconds. Server gives client a configured window to refresh token after `ttl` passed and then closes connection if client have not updated its token. -When connecting with already expired token an error will be returned (with code `110`). In this case client should refresh its token and reconnect with exponential backoff. +When connecting with already expired token an error will be returned (with code `109`). In this case client should refresh its token and reconnect with exponential backoff. ### RPC-like calls: publish, history, presence