0

We are creating an app using .net Compact Framework 3.5 running on Windows CE Embedded 7.0. This app is collecting different data from our different vehicles and sending them back to our Server.

The Problem we are facing is connection lost, which is happening a lot because the Reception sometimes is just terrible (tunnels, woods, etc.).

If the connection is lost for like 15 Minutes, a lot of data couldn't reach the server. Out question now is, what should we do with this data? Using one of the existing queue Frameworks? Creating our own?

Some things we need are or things that would be great:

  • The queue should be persistent, so if the device restarts the data isn't lost
  • Our server at the Moment is running ASP.NET WebApi, so it would be great if this could be used
  • We send different kinds of data, and some of this data has to reach the server before the other, so some kind of priority system would be needed
  • New data is more important than old

I have searched a lot but couldn't found anything. Have you guys any ideas?

I hope this is the right place, it seemed to be to specific for Software Recommendations. Thanks

TomTom86
  • 3
  • 1
  • 1

1 Answers1

0

I do not have a solution but customers are using either 3rd party frameworks, for example MCL, or write there own 'queue-based' syncing framework.

There is a nice article at MSDN

One solution is using a file based messaging system with a separate communicator process, decoupled form the main process. Each message (data) is a file and the communicator processes the files and updates either the main process or the remote data server. I have done some unidirectinal solution using ftp and one using eMails. The eMail system has the advantage of already being persistent and 'queue' based.

Another solution uses SMS to send updates and processing information to the client.

As I used Compact Framework queues to decouple the main process and the communication, I did not have the use to have these persist a warmboot. But just saving the queue object regulary on every EnQueue or DeQueue should not be a problem using serialization.

My hint is to use CF queues and persist them using serialization. It makes no difference if you then use a Web Service or whatever to transfer the data between the server and the clients. Did you think about concurrent updates and sync errors for duplicate updates of same server data, or will this be no issue?

OTOH MS offers a sync framework for SQL Server/SQL Server Compact that handles data sync. It needs and IIS on the SQL Server side.

josef
  • 5,951
  • 1
  • 13
  • 24