Sockets will try to reconnect upon disconnection with an exponentially
rising backoff (configurable). However, if it's unbounded, at a certain
point does it need to even try? Probably not. Instead there's now a
`max` option that defaults to a minute, and the backoff will never
exceed that time.
Changes behavior from only opening sockets when absolutely necessary to
keeping them open for as long as possible. Key differences:
- Much higher success rate for messages sent from the connected server.
- Process no longer shuts down if nothing is done with gun, instead
listens for incoming messages on client sockets.
Socket reconnect handle by Peer instances, meaning better handling for
deferred messages and predictable backoff.
The client.js logic has been significantly refactored. Among the
improvements, GET/PUT requests now respect the `peers` option for each
gun instance, only sending requests to the URLs listed.
The Peer "class" now extends EventEmitter. Listening to any websocket
events (e.g., "message", "close", "open", etc.) will not only subscribe
to the current websocket, but all future websockets. This provides a
much needed abstraction, since reconnection replaces the socket, which
would typically destroy your listeners.
Better de-duplication on messages sent for GET and PUT requests,
allowing full circular connections without blowing up your computer.
Sadly, this broke some things against the previous version, so per
@amark's request I'm publishing so he can debug.
If you're reading this commit history, please avert your eyes. 3
commits to fix this admittedly simple problem is more than my pride can handle.
The `gun.Back()` function was only searching for `opt`, not
`opt.file`. It would stop at the first mention of `opt` even if it
didn't have settings for `file`. Now it won't.
The FileJS module can be passed options in two ways, and this commit
ensures they're treated in the right way.
Previously, options passed as .put or .get parameters would be favored
over those used on the chain, even if `file` wasn't specified. Now, the
module will only use the method options if `file` is mentioned, falling
back to the chain options.
This was a mistake on my part with the first PR (#268), I failed to notice notice that edge case.
If you use gun a bunch, you've probably noticed the messages like "Hello
wonderful person :)" and "WARNING: This file.js module...".
This PR allows you to silence them.
Use `Gun.log.off = true` to bring peace back to your workflow.
> **Note:** great when used with file watchers like nodemon."
If the most recent gun options disable the file module, then it
won't try to read/write from the json. Previously it would. Also, now
you can override the behavior by passing `{ file: false }` as the
options in `gun.put`.
Servers will now try to initiate a connection using websockets if the
`peers` option is set. Currently, it'll either start throwing errors,
or generate a broadcasting storm. Still work to be done...
This marks a milestone of getting the servers to connect to each
other. Now to have those messages make sense. Committing so I
have an easy rollback point.
The `wsp.server` logic was never making it to the /gun.js route. If the
browser is just sending a GET request for a the js file, it won't set
the upgrade property, and the server logic wouldn't let the request pass
if it didn't have that header.
I've simply moved the check below the file serving logic.
