ive a sever running TIdTCPServer, and Client Using Web Browser (or any other software) to Communicate, i dunno the protocol, but what im trying to do is to Send The Data between the client and another Connection (Both Connected to the same TIdTCPServer) for example the data sent by the first client is transmitted to the second client, and the data sent by the second client is transmitted to the first client, like a proxy (i cant really use a proxy server since its just this one condition) and the TIdTCPServer should still be receiving other clients and processing their data.
i stumbled upon the first line of code, since TIdContext.Connection.Socket.ReadLn requires a Delimiter, and the Client's Protocol is unknown to the server.
any ideas?
thanks.
You can look at the source code for TIdMappedPortTCP and TIdHTTPProxyServer to see how they pass arbitrary data between connections in both directions. Both components use TIdSocketList.SelectReadList() to detect when either connection has data to read. TIdMappedPortTCP then uses TIdBuffer.ExtractToBytes() and TIdIOHandler.Write(TIdBytes), whereas TIdHTTPProxyServer uses TIdTCPStream and TIdBuffer.ExtractToStream() instead.
Related
Hi is it possible to create intermediary application which will act as tcp proxy server? It would be made of two components. IdTCPServer and IdTCPClient. The idea is:
Application > connects to IdTCPServer > all data is redirected to > IdTCPClient which is connected to the destination.
And the data received by TCPClient will be redirected to the IdTCPServer and Application.
I made such simple app, and it works in HTTP requests, but it fails when I tried to use it for RDP Client ( I got error that Protocol is wrong). Is it even possible? I use ReadByte method, and each single byte is sent to the other IOHandler.
I would like to create some sort of virtual tcp channel which would allow connections over NAT.
I wasn't clear enough. What I want to achieve is something like this:
RDP Server < IdTCPClient <> IdTCPclient > NAT > IdTCPServer < RDPClient.
Application > connects to IdTCPServer > all data is redirected to > IdTCPClient which is connected to the destination.
And the data received by TCPClient will be redirected to the IdTCPServer and Application.
In fact, Indy has a component specifically for that very purpose - TIdMappedPortTCP.
Set its MappedHost and MappedPort properties to point at the intended destination, then activate it, and all inbound connections will automatically be directed to the destination, and data passed back and forth in both directions.
I was going to add just a comment, but don't have enough points for that.
Your request says you want to "redirect", for which Remy supplied the answer.
However, your description sounds like you want to pass the data yourself (man-in-the-middle). RDP contains some guards against that, though earlier versions may have been more open to it.
You may want to specify the question more tightly if actual redirect is not what you are looking for.
I am trying to use EventSource on the client side and
one the server side I am using HttpRequest.response
which returns an object of type HttpResponse.
I am using HttpResponse.write to write events back
to the client side but it seems that these events
are only actually written (i.e., flushed) when the
HttpResponse object is closed, which implies also
closing the client-server communication server.
This kind of defeats the purpose of using EventSource.
Am I doing something wrong?
What you want to be looking at if you want to keep the connection between client and server alive between requests is called WebSockets.
See this tutorial for examples: https://www.dartlang.org/docs/dart-up-and-running/contents/ch05.html
I have an app running where a socket connection is constantly maintained (using socket.io). Data that needs to be sent is similar to that which you might see in a chat application. Would it be better to have it sent through POST (essentially, post that data, prevent page redirect, and then return the new page state with websockets), or just send it through websockets? What are the advantages to each?
(You might want to explain what you're trying to accomplish in more detail. Do you want to implement chat-like functionality).
A WebSocket gives you a TCP-like connection protocol over an HTTP connection. It's full duplex and lets you push and pull content in both directions. The connection is initiated from HTTP which "upgrades" the connection type. It gives you flexibility with some added complexity. I don't think it works across old HTTP 1.0 proxies.
A simple HTTP POST is more brute force. Unless you use ajax-ish techniques it pushes data to a web service and responds with a new web page to replace whatever's in your browser.
Situation: Two web servers, and a browser client. The client has an open websockets connection with Server A. Server A decides that this client should really be serviced by Server B.
I would like to know if there is any established technique for performing this hand-over?
It would be great if this could happen as invisibly as possible for my client side code - but I haven't come across any feature which would allow this.
Best I have come up with so far is Server A sending a 'you should really deal with Server X' message, client closing the WS session and then sending some http request which will get routed to the correct server, and upgraded to WS. I can see the presense of load balancers making this complicatied though.
Any thoughts?
From a programming point of view, the socket connection is treated as an open file handle, and that's what you are trying to pass along. For that, I would check out the question "Portable way to pass file descriptor between different processes" for a handful of methods.
But if you are not writing your own web server, and are looking for an off-the-shelf method for Apache, etc, this probably won't help you much.
I need to program a stateless server to execute remote methods. The client uses REST with a JSON parameter to pass the method name and its parameters. After servicing the result the session is closed. I have to use Indy10, TCP/IP as protocol, and therefore look at using IdHTTPServer.
Large result sets are chunked by Indy10 and sent to the client in parts.
My problem now is:
The methods on the server provide progress information if they take longer to produce the results. These are short messages. How can I write back to the client?
So far I have used writeflush on the server, but the client waited for the request to end before handing back the full resultset, including the progress information. What can I do to display/process such progress information on the client and yet keep the connection open to receive further data on the same request?
On the client side instead of the regular HTTP client component TIdHTTP you can instead use Indy class TIdTCPClientCustom in unit IdTCPClient to send the request and process the response.
This class gives total control over the processing of the server responses. I used the TIdTelnet class as a starting point to implement a client for a message broker messaging protocol, and found it stable and reliable for both text and binary data.
In the receiving thread, the incoming data can be read up to delimiters and parsed into chunks (for the progress information) and immediately processed.