Question about IdMappedPortTCP 2

[cappe]

Hi everyone.

I should change the port at runtime and that's no problem, but I can't manage the packet passing, does anyone have an example. I would like to see the content.
I have no idea how to do it.

[Remy Lebeau]

I can't manage the packet passing

Please be more specific.  TIdMappedPortTCP handles the packets for you, you don't pass around anything yourself.

does anyone have an example.

Example of what, exactly?  What are you trying to accomplish?

I would like to see the content.

That is what the OnExecute and OnOutboundData events are meant for.

OnExecute is fired whenever TIdMappedPortTCP receives bytes from an inbound client.

OnOutboundData is fired whenever TIdMappedPortTCP receives bytes from a server that it had reached out to.

In both events, you can access (and modify) the bytes by type-casting the TIdContext parameter to TIdMappedPortContext and then accessing its NetData property.

[cappe]

Hi Remy,
What i have to do i change the destination port based on some data contained in the packet.

Before answering you, I tried again to solve the problem and, fortunately, I managed to make it work with some help you gave me:

In the OnConnect event, manually read the URL from the Context.Connection.IOHandler, then setup the TIdMappedPortContext.OutboundClient as I described earlier.  Any data that you read that needs to be sent to the destination, put it in the TIdMappedPortContext.NetData property, and then you can manually send it to the destination via the TIdMappedPortContext.OutboundClient in the OnOutboundConnect event.

I had previously tried this method, but failed.
While until now I had used the peek method to get part of the package and it worked, but now I wanted to try to get it all.
The thing works and I use it for websockets.
Does this component work well with multiple servers?
And after that I would like to try the httpproxyservers even if I am fine with IdMappedPortTcp .

Thank

[Remy Lebeau]

What i have to do i change the destination port based on some data contained in the packet.

Changing the port dynamically can be done in the OnConnect event, which is fired after a new TIdTCPClient is created but before it is Connect()'ed to the target server.  The TIdTCPClient.Port property can be accessed by type-casting the TIdMappedPortContext.OutboundClient property to TIdTCPClient.

To determine which port value to assign, you will have to manually read the necessary data from the inbound client, either in the OnBeforeConnect or OnConnect event, which are fired before TIdMappedPortTCP tries to connect the OutboundClient to the target server.  TIdMappedPortTCP does not begin reading data from the inbound client until after the OutboundClient is connected.

While until now I had used the peek method to get part of the package and it worked, but now I wanted to try to get it all.
The thing works and I use it for websockets.

That would require handling the complete WebSocket handshake inside of the OnBeforeConnect or OnConnect event, and then letting TIdMappedPortTCP forward the raw bytes of the WebSocket packets back and forth.

I don't think I would recommend using TIdMappedPortTCP as a WebSocket proxy, though it is possible, I supppose.  I would probably use TIdHTTPServer instead (since the WebSocket handshake is done over HTTP), or even write (or find) a dedicated WebSocket server instead.

Does this component work well with multiple servers?

It is not intended for that purpose, but it can be used for that, as evident by the information you already have.

And after that I would like to try the httpproxyservers even if I am fine with IdMappedPortTcp .

TIdHTTPProxyServer will not work as a WebSocket proxy.  It only understands very basic HTTP (and it is not a full HTTP implementation at that), and for an HTTP GET request (which the WebSocket handshake uses) it will close the connection once the HTTP request has been responded to by the target server.  So, there is no opportunity to handle the upgrade from HTTP to WebSocket, let alone to forward WebSocket packets back and forth.  Also, if the WebSocket client uses the HTTP CONNECT request to tunnel a TLS-encrypted connection, then the entire WebSocket handshake and subsequent packets will be encrypted, so you can't do anything with that data at all.

[cappe]

Is the best place to look at exchanged packet in onExecute?

[Remy Lebeau]

Is the best place to look at exchanged packet in onExecute?

I already addressed that in an earlier reply:

That is what the OnExecute and OnOutboundData events are meant for.

OnExecute is fired whenever TIdMappedPortTCP receives bytes from an inbound client.

OnOutboundData is fired whenever TIdMappedPortTCP receives bytes from a server that it had reached out to.

In both events, you can access (and modify) the bytes by type-casting the TIdContext parameter to TIdMappedPortContext and then accessing its NetData property.

Just note that TIdMappedPortTCP is meant to be a straight pass-through of data from one connection to another, the NetData property will hold arbitrary bytes on each event fired.  So, you would be responsible for manually buffering and parsing those bytes yourself as needed if you want to make any sense of them.

[cappe]

Thanks and sorry if I was repetitive.