mirrors/FreeRDP
0
0
Fork 0
mirror of https://github.com/FreeRDP/FreeRDP.git synced 2024-11-28 04:14:08 +08:00
Code Issues Packages Projects Releases Wiki Activity
dcefd4f861
FreeRDP/include/freerdp/autodetect.h

145 lines
6.3 KiB
C
Raw Normal View History

autodetect: prepare for multi-transport Autodetect packets can be transported either in TCP TPKT packets or be contained in multi-transport subheaders (transported on UDP). These changes do the appropriate modifications so that in further developments we can take the transport type in account when treating / writing these packets.
2022-11-16 16:53:01 +08:00
/**
* FreeRDP: A Remote Desktop Protocol Implementation
* Auto-Detect PDUs
*
* Copyright 2014 Dell Software <Mike.McDonald@software.dell.com>
* Copyright 2014 Vic Lee
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
#ifndef FREERDP_AUTODETECT_H
#define FREERDP_AUTODETECT_H
#include <freerdp/api.h>
[includes] untangled circular includes
2023-03-14 17:39:18 +08:00
#include <freerdp/types.h>
autodetect: prepare for multi-transport Autodetect packets can be transported either in TCP TPKT packets or be contained in multi-transport subheaders (transported on UDP). These changes do the appropriate modifications so that in further developments we can take the transport type in account when treating / writing these packets.
2022-11-16 16:53:01 +08:00
#ifdef __cplusplus
extern "C"
{
#endif
[autodetect] expose AUTODETECT_STATE
2023-02-09 18:13:44 +08:00
typedef enum
{
core/autodetect: Rework server side API to be closer to documentation The current state of the autodetect API for the server side does not include all allowed scenarios where the network autodetection can be used. This for example includes the connect-time autodetection, as the related calls are hidden inside FreeRDP, and not exposed as public API. In order to avoid duplicate send methods, check the state of the connection sequence. If the connection sequence is not yet done, use the connect-time request types. Otherwise, use the continuous request types. The Bandwidth Measure Payload PDU is a little special case, as it is only allowed to be sent during the connection sequence. To ensure this, add an assertion in its sending method. Also fix the handling for the Network Characteristics Sync PDU: Previously, after parsing the PDU data, the read data was just sent again to the client, which is wrong. To fix this issue, introduce a callback for this client-to-server PDU, so that the actual server implementation can hook up its own handling for this PDU. Depending on the situation, the server side may want to discard or use the retrieved data here. Moreover, decouple the send-handling for the Network Characteristics Result PDU from the local autodetect variables. Currently, these variables are shared between the send and receive methods. This leads to access problems, where the server side, wants to use a different thread to send the autodetect PDU, as the receive handler may receive an autodetect PDU and overwrite these values with possible nonsense values. This is especially the case with RTT response PDUs, as the written netCharAverageRTT and netCharBaseRTT values are only correct, when only one RTTRequest happens at a time and no stray RTTResponses are received.
2023-04-09 15:59:34 +08:00
FREERDP_AUTODETECT_STATE_INITIAL,
FREERDP_AUTODETECT_STATE_REQUEST,
FREERDP_AUTODETECT_STATE_RESPONSE,
FREERDP_AUTODETECT_STATE_COMPLETE,
FREERDP_AUTODETECT_STATE_FAIL
} FREERDP_AUTODETECT_STATE;
typedef enum
{
[enum types] add *_RESERVED = 0 entries eliminate warnings with initializing a struct with = { 0 } due to enum members that do not define the value 0
2023-11-24 16:05:25 +08:00
RDP_NETCHAR_RESERVED = 0x0000U,
core/autodetect: Rework server side API to be closer to documentation The current state of the autodetect API for the server side does not include all allowed scenarios where the network autodetection can be used. This for example includes the connect-time autodetection, as the related calls are hidden inside FreeRDP, and not exposed as public API. In order to avoid duplicate send methods, check the state of the connection sequence. If the connection sequence is not yet done, use the connect-time request types. Otherwise, use the continuous request types. The Bandwidth Measure Payload PDU is a little special case, as it is only allowed to be sent during the connection sequence. To ensure this, add an assertion in its sending method. Also fix the handling for the Network Characteristics Sync PDU: Previously, after parsing the PDU data, the read data was just sent again to the client, which is wrong. To fix this issue, introduce a callback for this client-to-server PDU, so that the actual server implementation can hook up its own handling for this PDU. Depending on the situation, the server side may want to discard or use the retrieved data here. Moreover, decouple the send-handling for the Network Characteristics Result PDU from the local autodetect variables. Currently, these variables are shared between the send and receive methods. This leads to access problems, where the server side, wants to use a different thread to send the autodetect PDU, as the receive handler may receive an autodetect PDU and overwrite these values with possible nonsense values. This is especially the case with RTT response PDUs, as the written netCharAverageRTT and netCharBaseRTT values are only correct, when only one RTTRequest happens at a time and no stray RTTResponses are received.
2023-04-09 15:59:34 +08:00
/* The baseRTT and averageRTT fields are valid */
RDP_NETCHAR_RESULT_TYPE_BASE_RTT_AVG_RTT = 0x0840U,
/* The bandwidth and averageRTT fields are valid */
RDP_NETCHAR_RESULT_TYPE_BW_AVG_RTT = 0x0880U,
/* The baseRTT, bandwidth and averageRTT fields are valid */
RDP_NETCHAR_RESULT_TYPE_BASE_RTT_BW_AVG_RTT = 0x08C0U
} RDP_NETCHAR_RESULT_TYPE;
typedef enum
{
RDP_BW_RESULTS_RESPONSE_TYPE_CONNECTTIME = 0x0003,
RDP_BW_RESULTS_RESPONSE_TYPE_CONTINUOUS = 0x000B
} RDP_BW_RESULTS_RESPONSE_TYPE;
[autodetect] expose AUTODETECT_STATE
2023-02-09 18:13:44 +08:00
autodetect: prepare for multi-transport Autodetect packets can be transported either in TCP TPKT packets or be contained in multi-transport subheaders (transported on UDP). These changes do the appropriate modifications so that in further developments we can take the transport type in account when treating / writing these packets.
2022-11-16 16:53:01 +08:00
typedef struct rdp_autodetect rdpAutoDetect;
core/autodetect: Rework server side API to be closer to documentation The current state of the autodetect API for the server side does not include all allowed scenarios where the network autodetection can be used. This for example includes the connect-time autodetection, as the related calls are hidden inside FreeRDP, and not exposed as public API. In order to avoid duplicate send methods, check the state of the connection sequence. If the connection sequence is not yet done, use the connect-time request types. Otherwise, use the continuous request types. The Bandwidth Measure Payload PDU is a little special case, as it is only allowed to be sent during the connection sequence. To ensure this, add an assertion in its sending method. Also fix the handling for the Network Characteristics Sync PDU: Previously, after parsing the PDU data, the read data was just sent again to the client, which is wrong. To fix this issue, introduce a callback for this client-to-server PDU, so that the actual server implementation can hook up its own handling for this PDU. Depending on the situation, the server side may want to discard or use the retrieved data here. Moreover, decouple the send-handling for the Network Characteristics Result PDU from the local autodetect variables. Currently, these variables are shared between the send and receive methods. This leads to access problems, where the server side, wants to use a different thread to send the autodetect PDU, as the receive handler may receive an autodetect PDU and overwrite these values with possible nonsense values. This is especially the case with RTT response PDUs, as the written netCharAverageRTT and netCharBaseRTT values are only correct, when only one RTTRequest happens at a time and no stray RTTResponses are received.
2023-04-09 15:59:34 +08:00
typedef struct rdp_network_characteristics_result rdpNetworkCharacteristicsResult;
autodetect: prepare for multi-transport Autodetect packets can be transported either in TCP TPKT packets or be contained in multi-transport subheaders (transported on UDP). These changes do the appropriate modifications so that in further developments we can take the transport type in account when treating / writing these packets.
2022-11-16 16:53:01 +08:00
typedef BOOL (*pRTTMeasureRequest)(rdpAutoDetect* autodetect, RDP_TRANSPORT_TYPE transport,
UINT16 sequenceNumber);
typedef BOOL (*pRTTMeasureResponse)(rdpAutoDetect* autodetect, RDP_TRANSPORT_TYPE transport,
UINT16 sequenceNumber);
typedef BOOL (*pBandwidthMeasureStart)(rdpAutoDetect* autodetect, RDP_TRANSPORT_TYPE transport,
UINT16 sequenceNumber);
core/autodetect: Rework server side API to be closer to documentation The current state of the autodetect API for the server side does not include all allowed scenarios where the network autodetection can be used. This for example includes the connect-time autodetection, as the related calls are hidden inside FreeRDP, and not exposed as public API. In order to avoid duplicate send methods, check the state of the connection sequence. If the connection sequence is not yet done, use the connect-time request types. Otherwise, use the continuous request types. The Bandwidth Measure Payload PDU is a little special case, as it is only allowed to be sent during the connection sequence. To ensure this, add an assertion in its sending method. Also fix the handling for the Network Characteristics Sync PDU: Previously, after parsing the PDU data, the read data was just sent again to the client, which is wrong. To fix this issue, introduce a callback for this client-to-server PDU, so that the actual server implementation can hook up its own handling for this PDU. Depending on the situation, the server side may want to discard or use the retrieved data here. Moreover, decouple the send-handling for the Network Characteristics Result PDU from the local autodetect variables. Currently, these variables are shared between the send and receive methods. This leads to access problems, where the server side, wants to use a different thread to send the autodetect PDU, as the receive handler may receive an autodetect PDU and overwrite these values with possible nonsense values. This is especially the case with RTT response PDUs, as the written netCharAverageRTT and netCharBaseRTT values are only correct, when only one RTTRequest happens at a time and no stray RTTResponses are received.
2023-04-09 15:59:34 +08:00
typedef BOOL (*pBandwidthMeasurePayload)(rdpAutoDetect* autodetect,
RDP_TRANSPORT_TYPE transport, UINT16 sequenceNumber,
UINT16 payloadLength);
autodetect: prepare for multi-transport Autodetect packets can be transported either in TCP TPKT packets or be contained in multi-transport subheaders (transported on UDP). These changes do the appropriate modifications so that in further developments we can take the transport type in account when treating / writing these packets.
2022-11-16 16:53:01 +08:00
typedef BOOL (*pBandwidthMeasureStop)(rdpAutoDetect* autodetect, RDP_TRANSPORT_TYPE transport,
core/autodetect: Rework server side API to be closer to documentation The current state of the autodetect API for the server side does not include all allowed scenarios where the network autodetection can be used. This for example includes the connect-time autodetection, as the related calls are hidden inside FreeRDP, and not exposed as public API. In order to avoid duplicate send methods, check the state of the connection sequence. If the connection sequence is not yet done, use the connect-time request types. Otherwise, use the continuous request types. The Bandwidth Measure Payload PDU is a little special case, as it is only allowed to be sent during the connection sequence. To ensure this, add an assertion in its sending method. Also fix the handling for the Network Characteristics Sync PDU: Previously, after parsing the PDU data, the read data was just sent again to the client, which is wrong. To fix this issue, introduce a callback for this client-to-server PDU, so that the actual server implementation can hook up its own handling for this PDU. Depending on the situation, the server side may want to discard or use the retrieved data here. Moreover, decouple the send-handling for the Network Characteristics Result PDU from the local autodetect variables. Currently, these variables are shared between the send and receive methods. This leads to access problems, where the server side, wants to use a different thread to send the autodetect PDU, as the receive handler may receive an autodetect PDU and overwrite these values with possible nonsense values. This is especially the case with RTT response PDUs, as the written netCharAverageRTT and netCharBaseRTT values are only correct, when only one RTTRequest happens at a time and no stray RTTResponses are received.
2023-04-09 15:59:34 +08:00
UINT16 sequenceNumber, UINT16 payloadLength);
autodetect: prepare for multi-transport Autodetect packets can be transported either in TCP TPKT packets or be contained in multi-transport subheaders (transported on UDP). These changes do the appropriate modifications so that in further developments we can take the transport type in account when treating / writing these packets.
2022-11-16 16:53:01 +08:00
typedef BOOL (*pBandwidthMeasureResults)(rdpAutoDetect* autodetect,
core/autodetect: Rework server side API to be closer to documentation The current state of the autodetect API for the server side does not include all allowed scenarios where the network autodetection can be used. This for example includes the connect-time autodetection, as the related calls are hidden inside FreeRDP, and not exposed as public API. In order to avoid duplicate send methods, check the state of the connection sequence. If the connection sequence is not yet done, use the connect-time request types. Otherwise, use the continuous request types. The Bandwidth Measure Payload PDU is a little special case, as it is only allowed to be sent during the connection sequence. To ensure this, add an assertion in its sending method. Also fix the handling for the Network Characteristics Sync PDU: Previously, after parsing the PDU data, the read data was just sent again to the client, which is wrong. To fix this issue, introduce a callback for this client-to-server PDU, so that the actual server implementation can hook up its own handling for this PDU. Depending on the situation, the server side may want to discard or use the retrieved data here. Moreover, decouple the send-handling for the Network Characteristics Result PDU from the local autodetect variables. Currently, these variables are shared between the send and receive methods. This leads to access problems, where the server side, wants to use a different thread to send the autodetect PDU, as the receive handler may receive an autodetect PDU and overwrite these values with possible nonsense values. This is especially the case with RTT response PDUs, as the written netCharAverageRTT and netCharBaseRTT values are only correct, when only one RTTRequest happens at a time and no stray RTTResponses are received.
2023-04-09 15:59:34 +08:00
RDP_TRANSPORT_TYPE transport, UINT16 sequenceNumber,
UINT16 responseType, UINT32 timeDelta,
UINT32 byteCount);
autodetect: prepare for multi-transport Autodetect packets can be transported either in TCP TPKT packets or be contained in multi-transport subheaders (transported on UDP). These changes do the appropriate modifications so that in further developments we can take the transport type in account when treating / writing these packets.
2022-11-16 16:53:01 +08:00
typedef BOOL (*pNetworkCharacteristicsResult)(rdpAutoDetect* autodetect,
RDP_TRANSPORT_TYPE transport,
core/autodetect: Rework server side API to be closer to documentation The current state of the autodetect API for the server side does not include all allowed scenarios where the network autodetection can be used. This for example includes the connect-time autodetection, as the related calls are hidden inside FreeRDP, and not exposed as public API. In order to avoid duplicate send methods, check the state of the connection sequence. If the connection sequence is not yet done, use the connect-time request types. Otherwise, use the continuous request types. The Bandwidth Measure Payload PDU is a little special case, as it is only allowed to be sent during the connection sequence. To ensure this, add an assertion in its sending method. Also fix the handling for the Network Characteristics Sync PDU: Previously, after parsing the PDU data, the read data was just sent again to the client, which is wrong. To fix this issue, introduce a callback for this client-to-server PDU, so that the actual server implementation can hook up its own handling for this PDU. Depending on the situation, the server side may want to discard or use the retrieved data here. Moreover, decouple the send-handling for the Network Characteristics Result PDU from the local autodetect variables. Currently, these variables are shared between the send and receive methods. This leads to access problems, where the server side, wants to use a different thread to send the autodetect PDU, as the receive handler may receive an autodetect PDU and overwrite these values with possible nonsense values. This is especially the case with RTT response PDUs, as the written netCharAverageRTT and netCharBaseRTT values are only correct, when only one RTTRequest happens at a time and no stray RTTResponses are received.
2023-04-09 15:59:34 +08:00
UINT16 sequenceNumber,
const rdpNetworkCharacteristicsResult* result);
autodetect: prepare for multi-transport Autodetect packets can be transported either in TCP TPKT packets or be contained in multi-transport subheaders (transported on UDP). These changes do the appropriate modifications so that in further developments we can take the transport type in account when treating / writing these packets.
2022-11-16 16:53:01 +08:00
typedef BOOL (*pClientBandwidthMeasureResult)(rdpAutoDetect* autodetect,
RDP_TRANSPORT_TYPE transport, UINT16 responseType,
UINT16 sequenceNumber, UINT32 timeDelta,
UINT32 byteCount);
core/autodetect: Rework server side API to be closer to documentation The current state of the autodetect API for the server side does not include all allowed scenarios where the network autodetection can be used. This for example includes the connect-time autodetection, as the related calls are hidden inside FreeRDP, and not exposed as public API. In order to avoid duplicate send methods, check the state of the connection sequence. If the connection sequence is not yet done, use the connect-time request types. Otherwise, use the continuous request types. The Bandwidth Measure Payload PDU is a little special case, as it is only allowed to be sent during the connection sequence. To ensure this, add an assertion in its sending method. Also fix the handling for the Network Characteristics Sync PDU: Previously, after parsing the PDU data, the read data was just sent again to the client, which is wrong. To fix this issue, introduce a callback for this client-to-server PDU, so that the actual server implementation can hook up its own handling for this PDU. Depending on the situation, the server side may want to discard or use the retrieved data here. Moreover, decouple the send-handling for the Network Characteristics Result PDU from the local autodetect variables. Currently, these variables are shared between the send and receive methods. This leads to access problems, where the server side, wants to use a different thread to send the autodetect PDU, as the receive handler may receive an autodetect PDU and overwrite these values with possible nonsense values. This is especially the case with RTT response PDUs, as the written netCharAverageRTT and netCharBaseRTT values are only correct, when only one RTTRequest happens at a time and no stray RTTResponses are received.
2023-04-09 15:59:34 +08:00
typedef BOOL (*pNetworkCharacteristicsSync)(rdpAutoDetect* autodetect,
RDP_TRANSPORT_TYPE transport, UINT16 sequenceNumber,
UINT32 bandwidth, UINT32 rtt);
autodetect: prepare for multi-transport Autodetect packets can be transported either in TCP TPKT packets or be contained in multi-transport subheaders (transported on UDP). These changes do the appropriate modifications so that in further developments we can take the transport type in account when treating / writing these packets.
2022-11-16 16:53:01 +08:00
typedef BOOL (*pRxTxReceived)(rdpAutoDetect* autodetect, RDP_TRANSPORT_TYPE transport,
UINT16 requestType, UINT16 sequenceNumber);
core/autodetect: Allow overriding connect-time autodetection handling Currently, FreeRDP-based server implementations can do connect-time autodetection. However, without having any control over it. In order to be able to override the default connect-time autodetection handling, introduce three new states for the state machine of the connection sequence and two new callbacks for the autodetect handling. These are: - CONNECTION_STATE_CONNECT_TIME_AUTO_DETECT_BEGIN - CONNECTION_STATE_CONNECT_TIME_AUTO_DETECT_IN_PROGRESS - CONNECTION_STATE_CONNECT_TIME_AUTO_DETECT_END - OnConnectTimeAutoDetectBegin() - OnConnectTimeAutoDetectProgress() The END state is pretty simple: When the autodetection is finished and the autodetect state is FREERDP_AUTODETECT_STATE_COMPLETE, transition into the next state of the connection sequence. The BEGIN state is entered, when capability-wise network autodetection is available. In this state, the OnConnectTimeAutoDetectBegin callback is called, the server implementation may initialize any related handling here. If the server implementation determines, that no further handling is required, it can end the autodetection phase by returning FREERDP_AUTODETECT_STATE_COMPLETE. If not, and an autodetection request is sent, it returns FREERDP_AUTODETECT_STATE_REQUEST. The state machine of the connection sequence will then switch into the IN_PROGRESS state. In the IN_PROGRESS state, any incoming PDU is handled first, then the OnConnectTimeAutoDetectProgress callback is called. Like in the BEGIN state, the return value will determine, whether the state machine of the connection sequence goes into the END state or goes into (or rather stays) in the IN_PROGRESS state.
2023-04-10 00:34:56 +08:00
typedef FREERDP_AUTODETECT_STATE (*pOnConnectTimeAutoDetect)(rdpAutoDetect* autodetect);
autodetect: prepare for multi-transport Autodetect packets can be transported either in TCP TPKT packets or be contained in multi-transport subheaders (transported on UDP). These changes do the appropriate modifications so that in further developments we can take the transport type in account when treating / writing these packets.
2022-11-16 16:53:01 +08:00
core/autodetect: Rework server side API to be closer to documentation The current state of the autodetect API for the server side does not include all allowed scenarios where the network autodetection can be used. This for example includes the connect-time autodetection, as the related calls are hidden inside FreeRDP, and not exposed as public API. In order to avoid duplicate send methods, check the state of the connection sequence. If the connection sequence is not yet done, use the connect-time request types. Otherwise, use the continuous request types. The Bandwidth Measure Payload PDU is a little special case, as it is only allowed to be sent during the connection sequence. To ensure this, add an assertion in its sending method. Also fix the handling for the Network Characteristics Sync PDU: Previously, after parsing the PDU data, the read data was just sent again to the client, which is wrong. To fix this issue, introduce a callback for this client-to-server PDU, so that the actual server implementation can hook up its own handling for this PDU. Depending on the situation, the server side may want to discard or use the retrieved data here. Moreover, decouple the send-handling for the Network Characteristics Result PDU from the local autodetect variables. Currently, these variables are shared between the send and receive methods. This leads to access problems, where the server side, wants to use a different thread to send the autodetect PDU, as the receive handler may receive an autodetect PDU and overwrite these values with possible nonsense values. This is especially the case with RTT response PDUs, as the written netCharAverageRTT and netCharBaseRTT values are only correct, when only one RTTRequest happens at a time and no stray RTTResponses are received.
2023-04-09 15:59:34 +08:00
struct rdp_network_characteristics_result
{
/* Specifies, which fields are valid */
RDP_NETCHAR_RESULT_TYPE type;
/* Lowest detected round-trip time in milliseconds. */
UINT32 baseRTT;
/* Current average round-trip time in milliseconds. */
UINT32 averageRTT;
/* Current bandwidth in kilobits per second. */
UINT32 bandwidth;
};
autodetect: prepare for multi-transport Autodetect packets can be transported either in TCP TPKT packets or be contained in multi-transport subheaders (transported on UDP). These changes do the appropriate modifications so that in further developments we can take the transport type in account when treating / writing these packets.
2022-11-16 16:53:01 +08:00
struct rdp_autodetect
{
ALIGN64 rdpContext* context; /* 0 */
/* RTT measurement */
ALIGN64 UINT64 rttMeasureStartTime; /* 1 */
/* Bandwidth measurement */
ALIGN64 UINT64 bandwidthMeasureStartTime; /* 2 */
ALIGN64 UINT64 bandwidthMeasureTimeDelta; /* 3 */
ALIGN64 UINT32 bandwidthMeasureByteCount; /* 4 */
/* Network characteristics (as reported by server) */
core/autodetect: Rework server side API to be closer to documentation The current state of the autodetect API for the server side does not include all allowed scenarios where the network autodetection can be used. This for example includes the connect-time autodetection, as the related calls are hidden inside FreeRDP, and not exposed as public API. In order to avoid duplicate send methods, check the state of the connection sequence. If the connection sequence is not yet done, use the connect-time request types. Otherwise, use the continuous request types. The Bandwidth Measure Payload PDU is a little special case, as it is only allowed to be sent during the connection sequence. To ensure this, add an assertion in its sending method. Also fix the handling for the Network Characteristics Sync PDU: Previously, after parsing the PDU data, the read data was just sent again to the client, which is wrong. To fix this issue, introduce a callback for this client-to-server PDU, so that the actual server implementation can hook up its own handling for this PDU. Depending on the situation, the server side may want to discard or use the retrieved data here. Moreover, decouple the send-handling for the Network Characteristics Result PDU from the local autodetect variables. Currently, these variables are shared between the send and receive methods. This leads to access problems, where the server side, wants to use a different thread to send the autodetect PDU, as the receive handler may receive an autodetect PDU and overwrite these values with possible nonsense values. This is especially the case with RTT response PDUs, as the written netCharAverageRTT and netCharBaseRTT values are only correct, when only one RTTRequest happens at a time and no stray RTTResponses are received.
2023-04-09 15:59:34 +08:00
ALIGN64 UINT32 netCharBandwidth; /* 5 */
ALIGN64 UINT32 netCharBaseRTT; /* 6 */
ALIGN64 UINT32 netCharAverageRTT; /* 7 */
ALIGN64 BOOL bandwidthMeasureStarted; /* 8 */
ALIGN64 FREERDP_AUTODETECT_STATE state; /* 9 */
ALIGN64 void* custom; /* 10 */
[core,autodetect] improve logging * use dynamically allocated logger of context * improve stringification, print string representations with value for message and header types
2023-04-28 14:21:57 +08:00
ALIGN64 wLog* log; /* 11 */
UINT64 paddingA[16 - 12]; /* 12 */
autodetect: prepare for multi-transport Autodetect packets can be transported either in TCP TPKT packets or be contained in multi-transport subheaders (transported on UDP). These changes do the appropriate modifications so that in further developments we can take the transport type in account when treating / writing these packets.
2022-11-16 16:53:01 +08:00
ALIGN64 pRTTMeasureRequest RTTMeasureRequest; /* 16 */
ALIGN64 pRTTMeasureResponse RTTMeasureResponse; /* 17 */
ALIGN64 pBandwidthMeasureStart BandwidthMeasureStart; /* 18 */
core/autodetect: Rework server side API to be closer to documentation The current state of the autodetect API for the server side does not include all allowed scenarios where the network autodetection can be used. This for example includes the connect-time autodetection, as the related calls are hidden inside FreeRDP, and not exposed as public API. In order to avoid duplicate send methods, check the state of the connection sequence. If the connection sequence is not yet done, use the connect-time request types. Otherwise, use the continuous request types. The Bandwidth Measure Payload PDU is a little special case, as it is only allowed to be sent during the connection sequence. To ensure this, add an assertion in its sending method. Also fix the handling for the Network Characteristics Sync PDU: Previously, after parsing the PDU data, the read data was just sent again to the client, which is wrong. To fix this issue, introduce a callback for this client-to-server PDU, so that the actual server implementation can hook up its own handling for this PDU. Depending on the situation, the server side may want to discard or use the retrieved data here. Moreover, decouple the send-handling for the Network Characteristics Result PDU from the local autodetect variables. Currently, these variables are shared between the send and receive methods. This leads to access problems, where the server side, wants to use a different thread to send the autodetect PDU, as the receive handler may receive an autodetect PDU and overwrite these values with possible nonsense values. This is especially the case with RTT response PDUs, as the written netCharAverageRTT and netCharBaseRTT values are only correct, when only one RTTRequest happens at a time and no stray RTTResponses are received.
2023-04-09 15:59:34 +08:00
ALIGN64 pBandwidthMeasurePayload BandwidthMeasurePayload; /* 19 */
ALIGN64 pBandwidthMeasureStop BandwidthMeasureStop; /* 20 */
ALIGN64 pBandwidthMeasureResults BandwidthMeasureResults; /* 21 */
ALIGN64 pNetworkCharacteristicsResult NetworkCharacteristicsResult; /* 22 */
ALIGN64 pClientBandwidthMeasureResult ClientBandwidthMeasureResult; /* 23 */
ALIGN64 pNetworkCharacteristicsSync NetworkCharacteristicsSync; /* 24 */
ALIGN64 pRxTxReceived RequestReceived; /* 25 */
ALIGN64 pRxTxReceived ResponseReceived; /* 26 */
core/autodetect: Allow overriding connect-time autodetection handling Currently, FreeRDP-based server implementations can do connect-time autodetection. However, without having any control over it. In order to be able to override the default connect-time autodetection handling, introduce three new states for the state machine of the connection sequence and two new callbacks for the autodetect handling. These are: - CONNECTION_STATE_CONNECT_TIME_AUTO_DETECT_BEGIN - CONNECTION_STATE_CONNECT_TIME_AUTO_DETECT_IN_PROGRESS - CONNECTION_STATE_CONNECT_TIME_AUTO_DETECT_END - OnConnectTimeAutoDetectBegin() - OnConnectTimeAutoDetectProgress() The END state is pretty simple: When the autodetection is finished and the autodetect state is FREERDP_AUTODETECT_STATE_COMPLETE, transition into the next state of the connection sequence. The BEGIN state is entered, when capability-wise network autodetection is available. In this state, the OnConnectTimeAutoDetectBegin callback is called, the server implementation may initialize any related handling here. If the server implementation determines, that no further handling is required, it can end the autodetection phase by returning FREERDP_AUTODETECT_STATE_COMPLETE. If not, and an autodetection request is sent, it returns FREERDP_AUTODETECT_STATE_REQUEST. The state machine of the connection sequence will then switch into the IN_PROGRESS state. In the IN_PROGRESS state, any incoming PDU is handled first, then the OnConnectTimeAutoDetectProgress callback is called. Like in the BEGIN state, the return value will determine, whether the state machine of the connection sequence goes into the END state or goes into (or rather stays) in the IN_PROGRESS state.
2023-04-10 00:34:56 +08:00
ALIGN64 pOnConnectTimeAutoDetect OnConnectTimeAutoDetectBegin; /* 27 */
ALIGN64 pOnConnectTimeAutoDetect OnConnectTimeAutoDetectProgress; /* 28 */
UINT64 paddingB[32 - 29]; /* 29 */
autodetect: prepare for multi-transport Autodetect packets can be transported either in TCP TPKT packets or be contained in multi-transport subheaders (transported on UDP). These changes do the appropriate modifications so that in further developments we can take the transport type in account when treating / writing these packets.
2022-11-16 16:53:01 +08:00
};
FREERDP_API rdpAutoDetect* autodetect_get(rdpContext* context);
#ifdef __cplusplus
}
#endif
#endif /* FREERDP_AUTODETECT_H */
Reference in New Issue Copy Permalink