3

I'm working on a project where I have to trigger my windows desktop app to fetch the database for new rows once a user on the internal network send new requests.

I have managed to hack this around through several ways:

  1. A timer on the C# desktop app with half a second interval.
  2. The PHP webapp creates an XML file with the requests on the OS where the C# app is hosted then the File System Watcher class does the job.
  3. SOAP PHP web service and consume it in C#.

Is there a clean direct way to do this? because I don't like any of the hacks I did as it's full of bugs.

5
  • "Full of bugs" is a bit vague. Option 1 is as sensible as anything else, and has the virtue of simplicity. What's the problem? Commented Oct 9, 2016 at 15:21
  • the file system watcher for instance works only on the first time and the app must be restarted after that, the timer looks like a hack for me because of performance and the third option doesn't work at all sometimes Commented Oct 9, 2016 at 15:24
  • Is it a MS-SQL server? Commented Oct 9, 2016 at 19:26
  • @AdrianIftode it's MySQL Commented Oct 10, 2016 at 12:29
  • @Caddy, I deleted my answer since now is useless. Maybe MySQL has a similar concept of pub/sub for certain queries. Commented Oct 10, 2016 at 12:40

2 Answers 2

1

For inter-process communication like this, I would look into TCP/IP Sockets.

enter image description here

It's a simple, direct way to provide communication between one program and another. The CodeProject article below will help you get started.

Further Reading
TCP/IP Chat Application Using C#
PHP: Sockets

6
  • 1
    Considering he is using PHP he is much better off using something like RabbitMQ and setting up workers of a queue from the C# app. Commented Oct 9, 2016 at 19:03
  • @DavidPacker: Why? Just saying something is true doesn't really help anyone. Commented Oct 10, 2016 at 14:54
  • 2
    PHP is meant to die after each request, meaning it cannot really (well it can with hacks like Ratchet) hold a persistent connection between the client and the server. This means the PHP script would need to somehow store the currently connected clients (which is unreliable). By asynchronously pushing a durable message to a queue and having the clients consume from it whenever a new message appears you remove the tight coupling between the client and servers whilst keeping the communication. Would the server be Node.js, the AMQP wouldn't be necessary. Commented Oct 10, 2016 at 15:16
  • @DavidPacker: Your comments really should be an answer. I was going to write the same exact thing as an answer, until I read your comments. Commented Oct 10, 2016 at 16:37
  • 1
    @GregBurghardt Feel free to do so, Greg. I am here to learn and teach, not for the arbitrary karma points. :) Those are a nice bonus. Commented Oct 10, 2016 at 17:14
0

As @DavidPacker mentioned in one of his comments, an AMPQ server (like RabbitMQ) is your best bet. It's a publish/subscribe architecture.

  1. Your PHP application would publish a message to a certain queue.

  2. The C# application would be listening on that queue.

  3. Upon receiving this message, the C# application would query the database.

Each instance of the C# desktop application would be connected to the AMPQ server as a subscriber. These would be persistent connections similar to what @RobertHarvey's answer alludes to with his suggestion of using sockets. AMPQ uses sockets, but is a more focused, specific solution to your problem.

I've used this model before in a service oriented architecture with applications written in Java, C# and Ruby.

This decouples the publisher and subscriber, plus it is a technology agnostic messaging system giving you that bridge between technology stacks.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.