Merge pull request meteor#11960 from harryadel/patch-3

Fix broken links

packages/ddp/README.md

@@ -30,7 +30,7 @@ When using the sockjs transport, `ddp` has some special functionality to get aro
 
 ### Notable features
 
-**Database driver integration.** `ddp` works well with the Meteor Project's [full-stack database drivers](https://www.meteor.com/full-stack-db-drivers). For example, if you are using the `mongo` package, then when you create a Mongo collection with `MyCollection = new Mongo.Collection("mycollection")` on the client, the Mongo driver will automatically register with `ddp` to receive incoming data for `mycollection` and use it to keep `MyCollection` up to date. In other words, it automatically wires up replication for all of your remote collections.
+**Database driver integration.** `ddp` works well with the Mongo [database drivers](https://docs.meteor.com/api/collections.html). For example, if you are using the `mongo` package, then when you create a Mongo collection with `MyCollection = new Mongo.Collection("mycollection")` on the client, the Mongo driver will automatically register with `ddp` to receive incoming data for `mycollection` and use it to keep `MyCollection` up to date. In other words, it automatically wires up replication for all of your remote collections.
 
 **Automatic latency compensation.** `ddp` includes a full
 implementation of fine-grained latency compensation, so users see
@@ -41,14 +41,14 @@ as necessary.
 
 **Transparent reconnection.** If the DDP client loses its connection to the server, it will automatically reconnect, transparently to the application. Any subscriptions will be re-established and resynchronized without disturbing the application, and any outstanding method calls will be retried. However, this retrying could lead to duplicate method calls if the connection is lost after the server has received the method call, but before the client reads the result. This can be avoided just as it is with REST, by including a unique code as a parameter to the method. A future version of DDP will solve this on the protocol level (see Future Work).
 
-**Authentication.** `ddp`'s authentication hooks work great with [Meteor Accounts](https://www.meteor.com/accounts), a set of packages which provides a full suite of authentication functionality, from password-based accounts with email verification and password recovery, to OAuth login using services like Facebook and Twitter.
+**Authentication.** `ddp`'s authentication hooks work great with [Meteor Accounts](https://docs.meteor.com/api/accounts.html), a set of packages which provides a full suite of authentication functionality, from password-based accounts with email verification and password recovery, to OAuth login using services like Facebook and Twitter.
 
 **Input sanitization.** On the server, you can use the `check` function, provided by the [match](https://atmospherejs.com/meteor/match) package, to easily validate the types of arguments passed by the client. Using a simple pattern language, you can also `check` whether objects have the expected keps and array elements have the right type. In production code, add the [audit-argument-checks](https://atmospherejs.com/meteor/audit-argument-checks) package, and `ddp` will make sure that every value passed from the client is validated with `check`, and throw an exception if not. But be careful. The check only happens after the code has run, so while it will catch the vast majority of sanitization failures, it's not a perfect guarantee of safety.
 
-**Tracker-aware.** `ddp` obeys the simple [Tracker](https://www.meteor.com/tracker) convention for transparent reactivity. Values such as the current connection status (are we online?), subscription readiness (is the `newsFeed` done loading or should we show a progress indicator?), and the currently logged-in user (what username should we show in the status area at the top of page?) all work as reactive variables.
+**Tracker-aware.** `ddp` obeys the simple [Tracker](https://docs.meteor.com/api/tracker.html) convention for transparent reactivity. Values such as the current connection status (are we online?), subscription readiness (is the `newsFeed` done loading or should we show a progress indicator?), and the currently logged-in user (what username should we show in the status area at the top of page?) all work as reactive variables.
 
 **Default connection.** Normally you open a DDP connection with `myconn = DDP.connect(url)`, and then work with the connection with calls like `myconn.subscribe("newsFeed")` or `myconn.call("transferBalance")`. But if you build and deploy your app with the other Meteor tools, then a DDP server instance is automatically set up on the server, and each client is configured to automatically open a connection to that server on startup. You can work then with this "default connection" and "default server" with easy aliases like `Meteor.subscribe` and `Meteor.call`.
 
 **Connection lifecycle hooks.** Servers can run code when connections are established or closed. This can be used to update the database to show which users are online, making it easily to create presence features like a live-updating "Friends Online Now" list.
 
-**CRUD boilerplate and quickstart packages.** The [full-stack database drivers](https://www.meteor.com/full-stack-db-drivers) provide some helpful functionality that is worth mentioning here, even though it is actually part of those database packages, not `ddp`. They provide general-purpose `create`, `update`, and `delete` methods for each database collection, so that it is not necessary to write methods for basic CRUD operations. A system of `allow` and `deny` rules is used to control what each user can do. And two "quickstart" packages are provided, for quick prototyping and to help new developers learn Meteor. The `insecure` package turns off `allow`/`deny` rule checking for the generic `create`, `update`, and `delete` methods. The `autopublish` package automatically subscribes every connected client to the full contents of every database collection.
+**CRUD boilerplate and quickstart packages.** The [full-stack database drivers](https://docs.meteor.com/api/collections.html) provide some helpful functionality that is worth mentioning here, even though it is actually part of those database packages, not `ddp`. They provide general-purpose `create`, `update`, and `delete` methods for each database collection, so that it is not necessary to write methods for basic CRUD operations. A system of `allow` and `deny` rules is used to control what each user can do. And two "quickstart" packages are provided, for quick prototyping and to help new developers learn Meteor. The `insecure` package turns off `allow`/`deny` rule checking for the generic `create`, `update`, and `delete` methods. The `autopublish` package automatically subscribes every connected client to the full contents of every database collection.