"Bo Berglund" <bo.berglund@telia.com> wrote in message
news:6j0603tt01oukngr9qr4sa17svo5h80kq0@4ax.com...
> Now I see that these components won't live any longer
Yes, they are still available. They are just not installed by default
anymore.
> Indy 9 is what is supplied by Borland with Delphi7,
> but these components are blocking and I can't for the
> life of me understand how I can ever get them to work...
Have you looked at the demos yet? Have you read the documentation
yet?
> So I am required to build a TCP server, which will listen on two
> ports, one is a "command" port and the other is a "state" port.
Use TIdTCPServer. You can configure both ports with one component,
via its Bindings property. Or you can use a separate TIdTCPServer for
each port.
> On the main port the tool will connect to me and I am required
> to send back a command that basically tells the tool to also connect
> to the state port.
That is easy enough to do in the TIdTCPServer's OnConnect event.
Everything you can do in TServerSocket can be done in TIdTCPServer as
well.
> It will do so and then send a connect data packet on the "state"
> socket. After this it will wait for commands from me on the
> "command" socket and send event data on the "state" socket.
Also easy to do, using the TIdTCPServer's OnExecute event, or
accessing its Threads property.
> All data packets are strings formatted as XML (again dictade
> by the tool maker).
That makes no difference. Indy handles string data just fine.
> There is as far as I have seen no special termination character
> because the end bracket (>) repeats many times in the message text.
That is fine, as long as the XML is well-formed so all tags are closed
correctly.
> The closing tag of the XML string is what identifies the end of
message:
> </msg>. But this is a 6-char string....
So?
> The examples I have seen do not clearly show how the server
> (my program) can *send* commands to the connected client
> and retrieve the responses.
The same way you send and receive anything else in Indy - via the
various methods of TIdTCPConnection. TIdTCPServer maintains a
separate TIdTCPConnection object for each client connection. Just
make sure that your access to that object is thread-safe, as
TIdTCPServer is a multi-threaded component.
> Note that the examples do it the other way, a client connects to a
> server and then sends some command that gets replied to by the
server.
That is not a requirement. Both ways are possible with Indy.
> What methods on the server should I use to actually send a string
> to the connected client and retrieve its response???
Examples of doing what you are asking for have been posted many times
before. Go to http://www.deja.com to search through Borland's
archives, and go to news.adtozed.com to look through Indy's newsgroups
(there are no archives, but past messages are still on the server).
> The client (the tool) is supposed to send packets of data on the
> "state" socket at asynchronous intervals. Since Indy is blocking
> and thus there are no events, how can I ever retrieve these messages
> on the server side????
Use the OnExecute event. Simply call any of the TIdTCPConnection
reading methods in that event, and the event handler will wait for the
requested data to arrive from that client. Because TIdTCPServer is
multi-threaded, blocking the event of one client will not block the
events of other clients.
> In the old days I would simply collect the incoming data in the
> receive event and when the message is complete as determined
> by the length of the data (binary transfers) or some termination
> word, I would process the message.
You can do the exact same thing with TIdTCPServer. so all you have to
do is tell it what to read (ReadInteger(), ReadLn() with a terminator,
etc) and Indy will handle all of the waiting and buffering for you.
> Finally, my Indy with D7 is 9.0.10, must I upgrade in order to
create
> the TCP server outlined above?
No. But you should upgrade anyway, as that is a very old release of
Indy 9. The current Development Snapshot is 9.0.50.
Gambit
