[DRIVERS-2127] Clarify if OP_QUERY should always be used for monitoring and/or initial handshake Created: 02/Jan/20  Updated: 31/Mar/22

Status: Backlog
Project: Drivers
Component/s: OP_MSG, SDAM
Fix Version/s: None

Type: Spec Change Priority: Major - P3
Reporter: Kevin Albertson Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Driver Changes: Needed

 Description   

An ismaster is sent for (1) periodic SDAM monitoring and (2) during the initial handshake when opening a new socket to a server. It is not clear to me for both cases whether the ismaster should always be sent with OP_QUERY, or if we should use OP_MSG if the current server description indicates it supports OP_MSG. I think we should clarify in both cases which wire protocol to use.

OP_MSG spec says:

OP_MSG is only available in MongoDB 3.6 (maxWireVersion >= 6) and later. MongoDB drivers MUST continue to perform the MongoDB Handshake using OP_QUERY to determine if the node supports OP_MSG.
 
If the node supports OP_MSG, any and all messages MUST use OP_MSG, optionally compressed with OP_COMPRESSED.

I'm not sure if that means we should always use OP_QUERY for ismaster, or if we should use OP_MSG for ismaster if the current server description indicates that the server supports OP_MSG.

SDAM spec says that the reply to an initial handshake ismaster should also used to update the server/topology description.

If we're using the reply to the initial handshake to update our server/topology description, then the initial handshake is a part of monitoring as well. That indicates to me that if we decide to always use OP_QUERY for monitoring, we should always do so for the handshake.

FWIW, libmongoc always uses OP_QUERY for monitoring. And as was discovered in CDRIVER-3404, may use OP_MSG for the handshake if the last server description had a high enough maxWireVersion.



 Comments   
Comment by Divjot Arora (Inactive) [ 26/Feb/20 ]

I also agree that changing "node" to "connection" is more correct, but it is a detail that new driver implementations could easily miss. I like the idea of an "implementation notes" section with details like this.

Comment by Kevin Albertson [ 26/Feb/20 ]

I agree with Divjot's description as the intended behavior. Also relevant is to point 1 is the Warning about the maxWireVersion from a monitor's ismaster response section of SDAM, which says that application socket should not use the most recent server description saved during monitoring to determine the maxWireVersion. That implies the new application sockets should use OP_QUERY for the first handshake.

Changing "connection" to "node" seems reasonable. Perhaps we could take a succinct description like Divjot's comment and place that in the "Implementation notes" section of SDAM or in the new Server Monitoring spec? That could save future readers some investigation.

Comment by Shane Harvey [ 24/Feb/20 ]

What if we change this line to refer to "connection" instead of "node":

OP_MSG is only available in MongoDB 3.6 (maxWireVersion >= 6) and later. MongoDB drivers MUST continue to perform the MongoDB Handshake using OP_QUERY to determine if the connection supports OP_MSG.

If a connection supports OP_MSG, all future messages using the connection MUST use OP_MSG, optionally compressed with OP_COMPRESSED.

Comment by Jeffrey Yemin [ 24/Feb/20 ]

Note that streaming isMaster support will required OP_MSG for heartbeats, since it relies on the exhaustAllowed and moreToCome bits defined in OP_MSG.

CC shane.harvey

Comment by Divjot Arora (Inactive) [ 02/Jan/20 ]

I think the use of OP_QUERY/OP_MSG for handshakes and monitoring should be split up as follows:

  1. When a new connection is created, OP_QUERY should be used for the initial isMaster command, regardless of the driver's current view of the server. This is to ensure that a new connections can be established to a server that has downgraded to a pre-3.6 version. The server's isMaster reply should be used to determine the wire version for that connection. If that wire version is >= 6, the connection should use OP_MSG for the rest of the handshake (e.g. auth conversation). The Go driver originally did both the isMaster and the auth conversation using OP_QUERY, but we had a ticket from the Automation team to change this. The mongot server does not support OP_QUERY for non-isMaster commands, so new connections could not be created with auth.
  2. Monitoring threads should create a new connection per bullet 1. Future heartbeats should use OP_MSG if the server reported a wire version >= 6. This assumes that downgrading a server requires shutting it off, which would close all open connections on the server's side. In this case, if the server has downgraded in between heartbeats, the first heartbeat attempt would fail with a connection error. The monitoring thread would create a new connection per bullet 1 and the new connection would report a wire version < 6, so all future heartbeats would correctly use OP_QUERY.
Generated at Thu Feb 08 08:24:47 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.