[MXS-544] Protocol Module Investigations and Improvements Created: 2016-01-12 Updated: 2017-12-01 Resolved: 2016-06-14 |
|
| Status: | Closed |
| Project: | MariaDB MaxScale |
| Component/s: | Core |
| Affects Version/s: | None |
| Fix Version/s: | 2.0.0 |
| Type: | New Feature | Priority: | Major |
| Reporter: | Johan Wikman | Assignee: | martin brampton (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Sprint: | 1.4.0-1, 1.4.0-2, 2016-3, 2016-4, 2016-5, 2016-6, 2016-7, 2016-8, 2016-9, 2016-10, 2016-11 |
| Comments |
| Comment by martin brampton (Inactive) [ 2016-01-26 ] |
|
Initial action is to clarify the structure of headers that relate to protocols and SSL, with a view to separating SSL from a particular protocol, and enabling different protocols. The logic of this implies moving SSL configuration parameters from service sections to listener sections. SSL is not tied to any particular application level protocol, and it makes more sense to be able to have the option of SSL and non-SSL listeners for the same service (on different ports). Having to change the configuration logic brings one up against a whole host of problems including code quality in config.c |
| Comment by martin brampton (Inactive) [ 2016-02-09 ] |
|
SSL basic processing logic all moved into dcb.c as part of the core. Some more general SSL logic placed in new code file gw_ssl.c so as to keep SSL in defined locations. Number of calls from other areas minimised - poll.c contains call to accept a new connection on an EPOLLIN event when SSL connection is required but not complete. SSL is now specified as a property of listeners, instead of services. The same service can have an SSL listener and a non-SSL listener. The configuration guide has been updated to reflect the change and to clarify some points. Calls from the protocol and authentication logic to SSL have been reduced to the minimum necessary. In principle, SSL is now more readily applied to any protocol, rather than being tied into the MySQL protocol. The changes also help prepare the way for implementing SSL to back end servers. Actual authentication code for MySQL moved into a new code file mysql_auth.c. This now contains the checks that could (at least in theory) be used with a different communications protocol from MySQL. The organisation of the message exchanges remains in the simplified MySQL client protocol. Separation of the authentication code is a pre-requisite for creating each authentication mechanism as a module with its own API. |
| Comment by Dipti Joshi (Inactive) [ 2016-03-01 ] |
|
johan.wikman, Trying to understand if the protocol module improvement is for Binlog-Avro translator feature. Let me know. |
| Comment by martin brampton (Inactive) [ 2016-03-08 ] |
|
Clean up all protocols by creating dcb_accept and dcb_listen as common code for all protocols to handle the acceptance of new connections and the creation of listeners. Modify protocols to make use of them. Modify the set of roles for DCBs to make a clean separation between client related and back end server DCBs. Eliminate dcb_isclient() function rendered obsolete by the new roles. dshjoshi This task covers a general improvement in protocol code, which enables further development and the consolidation of SSL support. In particular a new task will be created now to handle the move to authentication modules. The authentication for Avro will be created as a module using the new mechanisms. The work being done here is also a basis for developing support for SSL on the server side of MaxScale. |
| Comment by Johan Wikman [ 2016-03-08 ] |
|
Moving to 1.5, since the tasks related to 1.4 have been made. |
| Comment by martin brampton (Inactive) [ 2016-03-23 ] |
|
MySQL backend protocol has been streamlined and checked to some extent. All protocol modules have been checked with lint at level -w2 and all errors and warnings cleared. Basic testing, including testing with failed backend, successful. |
| Comment by Johan Wikman [ 2016-03-23 ] |
|
martin brampton, it had been nice to have had that lint checking as a separate Jira item. |
| Comment by martin brampton (Inactive) [ 2016-04-19 ] |
|
Further work has been completed to deal with some problems introduced into MySQL backend protocol processing. Handling of the read queue has been changed so that a dcb_read will always return any data from the read queue ahead of any new data that can be read from the socket. After a read, the read queue is thus always empty. |