2
votes

I want to implement a demo application to listen data via TCP/IP. enter image description here

Data Transmitter will transmit a series or ASCII char or a series of string all the time. It feeds data into TCP/IP address (eg. 127.0.0.1:22) This could be a GPS transmitter.

I want to implement a demo application for receiving data by clicking the start button and listening to the data via TCP/IP and display it accordingly.

Correct me if I am wrong, I don't think I can use Server/Client server for this purpose. I tried to create a client application with TIdTcpClient, it receives only one time data. I don't think Indy has a TCP listening component.

Thanks in advance.

2
It is the TIdTCPServer that you were looking for. And it is a client/server design. Those data transmitters are clients sending their data to the server. - TLama
Hi TLama, Thanks for your comment. That's where I got confuse. If I use TIdTCPServer, I will get the exception 'Could not bind socket. Address and port are already in use'. I think Data Transmitter (from my scenario) is using that port. That's why I thought, it is not Client/Server design. - sMah
I missed that port number. Well, 22 is a default port for SSH protocol. And as far as I remember, Indy doesn't have a SSH protocol implementation. - TLama
I am sorry that I gave a bad example by choosing the port number as 22. The port number could be anything.(I will update the diagram, Thanks) I am more looking after TcpListener from C# similar in Delphi or Indy. msdn.microsoft.com/en-us/library/… - sMah

2 Answers

2
votes

If you wanna monitor network comunications between some device and some other program on your computer using of TIdTCPServer won't work. Why? Once Indy will read network data it will mark it as processed and delete it from network buffer. So that data probably won't even reach to the other program on your computer. Workaround for this is that you design your application to actually work similar as network bridge. Your application listens to the data on one port and then forwards that data on another port on which the other program is listening. But the main problem is that you have to make this to work both ways.

What you need is somekind of a component which is able to peek at the network data but don't interact with it. This is usually done on driver level.

Now if it is not abolutely necessary to have such functionality in your own software but you are only interested in getting the data I recomend you try Wireshark (http://www.wireshark.org/). Wireshark is a verry powerfull freware software which alows you to monitor all netwrok traffic on basically all protocols without causing any interuptions. In order for this software to work it instals special driver which serves for intercepting the network data.

Maybe you would want to use same driver in your application if this functionality needs to be in your application.

1
votes

Based on your diagram I think that your implementation could also be based on a message-oriented middleware, using a message broker which receives the GPS transmitter or other data.

The message broker would then store the data internally and forward it to all interested clients which are connected. A typical messaging pattern in this case is a "Topic", which broadcasts the messages similar to a radio station.

So the middleware will ensure that the information will be collected (optionally also persisted to disk) and then guarantees the delivery to the receivers. This can be done even in a way where receivers which have been off-line for a while still receive the GPS messages created while they where not listening ('retroactive consumers').

There are many popular free open source message brokers, and most of them also can be used with Delphi.