1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
|
/****************************************************************************
**
** Copyright (C) 2017-2016 Ford Motor Company
** Contact: https://www.qt.io/licensing/
**
** This file is part of the QtRemoteObjects module of the Qt Toolkit.
**
** $QT_BEGIN_LICENSE:LGPL$
** Commercial License Usage
** Licensees holding valid commercial Qt licenses may use this file in
** accordance with the commercial license agreement provided with the
** Software or, alternatively, in accordance with the terms contained in
** a written agreement between you and The Qt Company. For licensing terms
** and conditions see https://www.qt.io/terms-conditions. For further
** information use the contact form at https://www.qt.io/contact-us.
**
** GNU Lesser General Public License Usage
** Alternatively, this file may be used under the terms of the GNU Lesser
** General Public License version 3 as published by the Free Software
** Foundation and appearing in the file LICENSE.LGPL3 included in the
** packaging of this file. Please review the following information to
** ensure the GNU Lesser General Public License version 3 requirements
** will be met: https://www.gnu.org/licenses/lgpl-3.0.html.
**
** GNU General Public License Usage
** Alternatively, this file may be used under the terms of the GNU
** General Public License version 2.0 or (at your option) the GNU General
** Public license version 3 or any later version approved by the KDE Free
** Qt Foundation. The licenses are as published by the Free Software
** Foundation and appearing in the file LICENSE.GPL2 and LICENSE.GPL3
** included in the packaging of this file. Please review the following
** information to ensure the GNU General Public License requirements will
** be met: https://www.gnu.org/licenses/gpl-2.0.html and
** https://www.gnu.org/licenses/gpl-3.0.html.
**
** $QT_END_LICENSE$
**
****************************************************************************/
#ifndef QCONNECTIONQNXBACKEND_P_H
#define QCONNECTIONQNXBACKEND_P_H
//
// W A R N I N G
// -------------
//
// This file is not part of the Qt API. It exists purely as an
// implementation detail. This header file may change from version to
// version without notice, or even be removed.
//
// We mean it.
//
#include "qconnectionfactories_p.h"
#include "qconnection_qnx_qiodevices.h"
#include "qconnection_qnx_server.h"
QT_BEGIN_NAMESPACE
/*!
QtRO provides ClientIoDevice, ServerIoDevice and QConnectionAbstractServer
as abstract interfaces to allow different backends to be used by QtRO. The
concept behind these classes is that there needs to be a Host node, which
has an address that can be connected to. Then there is a client object,
which can be publicly constructed, and can connect to the server. When the
server gets a connection request, it creates the server side of the
connection, which communicates directly with the client. There are thus
three abstractions, one for the server, one for the client-side of the
connection, and the third for the server-side of the connection. The later
two need to inherit from QIODevice.
Creating a backend for something that is already implemented in Qt is a
matter of creating the three needed abstractions. In the case of creating a
QNX backend using QNX's Native Messaging, the backend needs to create the
Server (which has an address for accepting connections), the client
QIODevice, and the server side QIODevice. Since Native Messaging is one
way, and recommends using pulses to support two-way communication, the
logic for the client-side and server-side QIODevice are very different.
Thus, three additional backend classes are needed as well.
QnxClientIo implements the QtRO ClientIoDevice wrapper around the QNX
specific QQnxNativeIo QIODevice (the client-side QIODevice).
QnxServerIo implements the QtRO ServerIoDevice wrapper around the QNX
specific QIOQnxSource QIODevice (the server-side QIODevice).
QnxServerImpl implements the QtRO QConnectionAbstractServer wrapper around
the QNX specific QQnxNativeServer, which is the server object listening for
connections.
Not sure if it is of interest to the Qt community, but it seems like
QQnxNativeIo, QIOQnxSource and QQnxNativeServer could used as an optimized
QLocalServer/QLocalSocket QPA for QNX.
*/
class QnxClientIo final : public ClientIoDevice
{
Q_OBJECT
public:
explicit QnxClientIo(QObject *parent = nullptr);
~QnxClientIo();
QIODevice *connection() const override;
void connectToServer() override;
bool isOpen() const override;
public Q_SLOTS:
void onError(QAbstractSocket::SocketError error);
void onStateChanged(QAbstractSocket::SocketState state);
protected:
void doClose() override;
void doDisconnectFromServer() override;
private:
QQnxNativeIo *m_socket;
};
class QnxServerIo final : public ServerIoDevice
{
public:
explicit QnxServerIo(QSharedPointer<QIOQnxSource> conn, QObject *parent = nullptr);
QIODevice *connection() const override;
protected:
void doClose() override;
private:
//TODO Source or Replica
QSharedPointer<QIOQnxSource> m_connection;
};
class QnxServerImpl final : public QConnectionAbstractServer
{
Q_OBJECT
public:
explicit QnxServerImpl(QObject *parent);
~QnxServerImpl();
bool hasPendingConnections() const override;
ServerIoDevice *configureNewConnection() override;
QUrl address() const override;
bool listen(const QUrl &address) override;
QAbstractSocket::SocketError serverError() const override;
void close() override;
private:
QQnxNativeServer m_server;
};
QT_END_NAMESPACE
#endif // QCONNECTIONQNXBACKEND_P_H
|
