CODEWITHSUNDEEP
c#web-servicessockets
Andrew Simpson
Andrew Simpson

Reputation: 7344

What is best? Polling on a socket or waiting for a web service timeout?

I have a [web method]. What it does is look in a directory for *.dat files where the directory path is supplied by the client invoking the [web method].

At the moment the client invokes the [web method] and the code goes into a loop checking for any files. If it finds any it will return the listing. It can also obviously time out and when it does it my client code traps the error and re-invokes the [web method].

The alternative way of doing things is to open a TCP socket on the client and it will send a 'here I am' to a receiving socket service on the server. The server will look for existence of *.dats with criteria the client supplied to it. If it finds 1+ files it will send a '1' back. If no files it will send a '0' back. If the client receives a '1' from the server then my client app will then invoke the [web method] to retrieve the available listing.

I know I can use WCF for callbacks but I want to explicitly look at these 2 options 1st.

I am also aware of SignalR but I found out if I am using a pre-Windows 8 operating system then SignalR will revert to long polling as opposed to web sockets.

I can appreciate that doing the 1st method will put the 'emphasis' on the server and doing it the second way will evenly distribute the 'stresses' but will involve repetitive TCP calls.

I have done testing and both seem to hold their own.

Any opinions from anyone will be received with gratitude.

My objectives, is speed, low memory consumption, easy management of code, loose coupling between server and client - basically the obvious...

thanks...

Upvotes: 2

Views: 355

Answers (1)

Jens H
Jens H

Reputation: 4632

If you are looking for loose coupling then some implementation a Message Queue might help. Though this would mean you would need to change parts of your architecture.

I would suggest changing it into a "push" approach instead of polling.

My approach would be like this:

  • Each application/ service/ client of any kind registers for receiving the updates from your server.
  • Your service could use a FileSystemWatcher to check for your files. Let the .NET Framework do the dirty work, don't poll manually. :-)
  • Whenever new files arrive, the service publishes one message to all subscribers.

Optionally, you could implement a message dispatcher service that takes responsibility of the message subscriptions of the clients. This would separate the subscription management from your file service, which would feel cleaner to me.

The implementation details may vary on your choice of technologies.

At work, we have similar scenarios like yours, for which we are using WCF services that support the Microsoft Message Queue (MSMQ) out-of-the-box and for ease of use for it the NServiceBus framework. NServiceBus makes establishing those publisher/receiver scenarios easy to setup.

Of course there are lots of other Message Queue frameworks to use, this is just where I personally made good experiences with.

Upvotes: 1

Related Questions