[QEO] Expanding struct sizes in the future

[mtfriesen]

We pass an array of NDIS_QUIC_CONNECTION structs to NDIS. If we need to expand the size of the structure in the future, how does each NDIS component know how to walk the array?

IMO we should prefix each NDIS_QUIC_CONNECTION with a Size field at minimum, and perhaps a Version field. Thoughts?

[mtfriesen]

The question is probably applicable to the Winsock structs, too.

[nibanks]

I thought about this some, and I was thinking it was actually preferable to just have a different OID (i.e. *_V2) if we ever need to change the struct.

[mtfriesen]

We know that in the current implementation of Windows, at least, adding new direct OIDs is extremely expensive. We also have years of precedent from NDIS: NDIS structures are versioned. We introduce new OIDs when significant changes are made to an interface.

I'm not convinced that we should add a new OID any time we add a new crypto API, add some new compat flag, etc. It makes implementation and testing much harder.

[nibanks]

Ok, then instead of adding a version to each connection, what about a top-level struct such as:

typedef struct QEO_CONNECTION_SET {
    UINT32 Version;
    UINT32 Count;
    QEO_CONNECTION Connections[0];
};

And version can be used to control possibly using QEO_CONNECTION_V2 in the future?