Delphi Network Programming

I have a classic client / server program (bold client and database) written in Delphi 2006. When certain conditions are met in the client, I need to notify all other clients very quickly. So far, this has been done using UDP broadcasts, but this is more unviable since clients are now connecting from outside the local network and UDP broadcasting is limited to the local network.

I know the Indy libraries, but I'm not sure which components to use and how to structure them. I assume that I need to have a server to which clients connect, to which they will receive and distribute messages ...? Any samples to get me started?

Are there any other sets of components or technologies that I should look at instead?

+4
source share
7 answers

The simple answer is that the standard protocols available in Delphi (and other tools) do not allow notifications in the reverse order. I reviewed this for a project where I wanted to use SOAP. They all assume that the client is requesting a server, the server is responding, and that it is.

For me, the solution was the RemObjects SDK. This allows you to send notifications to clients, and the notification can have any data that you like (like the client to the server). I myself use the SuperTCP connection, but it works with others. It may still offer a SOAP interface for clients who need to use it, but for where you control the client and server, it works very well.

+4
source

There are some very easy ways to do this with Delphi, although I'm sure the RemObjects SDK works very well too.

  • You have a central server that has * TIdTCPServer listen * on it. Then each client has a TIdTCPClient on it. They connect to the server and block while reading , waiting for the server to write . As soon as the server receives a notification through the listening socket, it sends them to each of the waiting clients. This is an almost immediate notification of all customers.
  • Have a central server on which TIdTCPServer listen to g on it. Then each client has a TIdTCPClient . These clients can ping the server to request updates at regular intervals (use a session token to maintain state). The interval frequency determines how fast the notification will be. When one of the clients needs to notify others, it simply notifies the server. The server then uses the message queue to list all active client sessions and adds a notification for each. Then the next time each client connects, it receives a notification and removes it from the queue.
  • Maintain a session table in the database, where each client regularly updates its active session and deletes itself when it disconnects. You will need a maintenance process that removes dead sessions. Then you have a message queue table that the client can write an update with one row for each current active session. Other clients can then ping this table regularly to find out if there are pending notifications for its session, if they are, they can read them, and then delete them.
  • Some peer-to-peer approach was that clients know each other through information in the database, and then connect directly to each other and notify or request notifications (depending on the configuration of the firewall and NAT). A little harder, but possible.

Obviously, the choice of implementation will depend on your settings and needs. For best results, tuning is required.

For this you need TIdTCPServer (listener) and TIdTCPClient (sender). Both of them are in the Indy libraries in Delphi.

+2
source

The ICS components from http://www.overbyte.be are great. a.) Better compatibility than Indy b) Postcard Good examples and support. Use TClientSocket and TServerSocket

+1
source

The FirebirdSQL project uses the concept of notifications as server-to-client connections that send a string to a client. For this, the db server uses a different port. And ask the client to register it interesting to receive a certain type of notification using an API call.

You can use the same idea.

+1
source

RabbitMQ must match your score. The server is free and ready to use. You just need the client side to connect, send / send a message and receive / push a message

Server: http://www.rabbitmq.com/download.html Make Google for the client or realize yourself

Greetings

+1
source

You should be able to use Multicast UDP for the same purpose. The only difference is that you join the multicast group from each client.

http://en.wikipedia.org/wiki/IP_Multicast

http://en.wikipedia.org/wiki/Internet_Group_Management_Protocol

Edit: To clarify, multicast allows you to join this group associated with the multicast IP address. Any package sent to this address will be available to each client who joined the group.

0
source

You can see the wonVPN weonlydo component, which allows you to create reliable punching of UDP holes and get a through partition or a regular VPN (using a forked network adapter) so that you can connect two computers for NAT.

I use this control for our communication program and it works very well.

0
source

Source: https://habr.com/ru/post/1276661/


All Articles