Real time resource tracking use case

I am trying to prototype a system for tracking resources. A resource can be anything (car, person, place etc…) I am trying to prototype two use cases.

1. Cab tracking scenario;
   
   1. Vehicles publishes it's location to server
   2. Server stores the current location in a database for history & other info
   3. Pass the vehicle location coordinates to subscribers fleet owners to visually see their vehicles on a map
   4. Traveler can request a cab to his current location
   5. Traveler can see the location of his cab if it's confirmed (only the assigned cab can be seen by the traveler since vehicles are always publishing it's locations)

1. Location based queries
   
   1. There are certain data stored in DB with coordinates related to the stored resources (ex:- restaurants)
   2. A user set a rule (ex:- Alert me if there are vegetarian restaurants within 1km of my current location)
   3. As user navigates; current location is passed to server which performs a geo query in database existing data and return data if any matches the rules.

After finding Lightstreamer I feel it's a better fit for this. I am trying to figure out how the data adapters be used for these two user cases. For example;



For fleet tracking; should I create a data adapter per fleet(ex:- cab service 1 & 2)?

How should be the data adapter operate for the 2nd use case?

What is the optimal subscription mode for this kind of use cases (DISTINCT?)

So... no response means what I have mentioned above is unrealistic? :(

Lightstreamer seems appropriate for the data exchange through the internet between the various actors involved.

For point 1.1, where the car position has to be uploaded, the sendMessage feature is available.

For point 1.5, where car positions have to be sent to travelers, MERGE mode seems more appropriate, because each new sample (i.e. position) obsoletes the previous ones. But if you want to ensure that many past observations are available for the sake of the graphic presentation, the DISTINCT also makes sense.

For point 1.3, where all car positions have to be sent at the same time, you can use multiple items.
But if the set of all cars is not constant, then it is a case of "two level push" and the set of cars can be kept updated with an item in COMMAND mode.

About the second use case:
If I understand correctly, there is a set of current matches that changes as the user moves. Hence, an item in COMMAND mode can be used, to add and remove elements from the set in real time.
In this case, the "item" corresponds to the result of a query, so the query must be in some way represented by the item name itself; how to do this is left to the application and clients and adapters must cooperate.
Since the query is based on the position (that, again, can be kept updated via sendMessage), this position, which is available to the Metadata Adapter, must be communicated to the Data Adapter.

About how to separate the items among multiple Data Adapters, we have no particular recommendations. It is a feature that you can leverage at your convenience.
Usually, different Data Adapters are associated with different channels to collect data from the back-end. Also note that if the clients wants to subscribe to multiple items in a single subscription operation, then all items must come from the same Data Adapter.

Thank you for the explanations! I have another question about the subscribing for items. In the documentation it says that we can subscribe to an ITEM which has fields (some sort of a schema). As I understood, we can subscribe to the item or a field in the item. Is it correct?

If that is the case; For one of my scenarios I can have a parent item (company) & fields for each car that belongs to the company. So, for any employee they can subscribe to "company" item and get all updates from vehicles under that item. If anyone want to monitor only one car, they can subscribe to the specific car field.

If my understanding is correct; I may be able to make a hierarchical schema like;

[Holding Company]
------Company1
-----------Monitor1
-----------Monitor2
------Company2

For the sake of precision, you can subscribe to an item AND you also have to specify the fields you are interested in.

Your use of the fields is not what we expect.
We assume that an item corresponds to some entity and that the fields are its attributes, so that the set of current field values makes up the current state of the item.
You can say that the state of the company is made of the positions of all its cars, but, since the cars are quite independent of one another, we would rather associate an item to each car.
In the latter case, in order to monitor all cars of a company, you would have to subscribe to all car-related items of that company.
This is not less efficient, and allows you to manage the addition or removal of a car with new subscriptions and unsubscriptions (for instance, by getting the current set of cars through an item in COMMAND mode, as already suggested). Note that, also with car-related fields, the set of subscribed fields is static: you cannot request "all available fields".
The only difference is that, with different items, the client cannot get the positions of multiple cars in a single update callback, but you will receive different updates in an unpredictable order, even if the car positions were sampled exactly at the same time. Would that be a limitation?

Ok, got it!. Not being able to get an update about the cars at the same time will not be an issue. However a concern I have is that if each car will work as an item (which makes sense as you said); in general there can be thousands of cars in a car rental company. So, is there a limitation in LightStreamer as to how many items it can handle at a time? If there is a limitation is it something to do with available server resources such as RAM or CPU cycles?

I suggest it'll be good to have a demo code prepared for this kind of a use-case. May be with a google map and some mock up geo-cords to simulate a vehicle marker moving on a map!

I confirm that the number of items that can be processed is only limited by system resources. The memory requirements of using items instead of fields (let's say two items with one field each versus one item with two fields) are certainly higher. But in a case in which only one client subscribes to all these items, the difference should not be of an order of magnitude.
Note that the client doesn't need to specify every single item upon subscription, as it can use a "group name" that will be expanded by the Metadata Adapter. The matter would be similar for fields, where you can specify a "schema name".

In terms of CPU, the operations upon each field update are similar in the two cases. If the updates provided by the back-end come in separate events for the different fields, then keeping them separated on different items may be beneficial.
But we don't have formulas to predict the impact and rely on customer tests on the specific scenarios.

I appreciate your suggestion and agree that this use case is suitable for a Lightstreamer demo. Since this is not our application field, do you have any sample code to share, particularly for a realistic car movement simulator?

At the moment I am building a mock-up application to simulate this use case and also to test the limits of Lightstreamer. I have talked to three car rental services and each of them has around 150-300 cars. Usually about 70%-90% of them are constantly active (taking passengers to destinations).

Considering the discussion we had, I thought to keep the car registration no. as the item name in the backend. Every car will push it's location every 5 seconds. Which means there can be around 600 items (600 cars from 3 car rental services). Now I am not sure whether 600 items is too much for Lightstreamer.

Then I got confused with one thing (May be too much forum reading, API docs etc... :D ). http://forums.lightstreamer.com/show...ndMessage+item

http://forums.lightstreamer.com/show...-back-using-LS

Problem is, individual car should only send it's location to it's own item which is named after car registration no in LS. Car owner(s) has a dashboard with a map where he subscribe to X amount of items (cars) from LS client. This is my problem. In the client, should I subscribe to each car item that i own? This seems very inefficient.

What if I have an item per owner where all the cars of that owner send it's location to one item(say company name). So any employees has only one item to watch for (similar to a chat room). Since all cars are now pushing to same item, to differentiate and do any processing we can send a car registration no and other data such as {car : XYZ, speed:10, distance:100} etc... At the place where LS picks the data, we can parse it and do whatever we want.

What do you think? I will surely submit the code once i get through this. At the moment I am confused about certain things.

The number of items is not a problem per se; it only adds some memory requirement, as said, but a light one. Tens of thousands of items are normally managed by production LS applications.
The heavy part can be the management of the update flow, particularly for the client, if it has to plot all positions of all cars. But this load is the same, regardless that the updates are related with multiple items or always the same.

Your proposal is also feasible; if I understand correctly, there is a single item with fixed fields which multiplexes the updates of the various cars. This can be done with DISTINCT mode, which (unlike MERGE mode) ensures that different updates are never conflated (so, if you update a car and omit a field, this field will not be filled with the previous update, which can refer to a different car).
Obviously, this is suitable for the clients which want to see all cars, not for clients interested in a single car.
The problem is that, if the overall flow is too heavy for the client and you try to leverage the frequency limit offered by Lightstreamer to resample the data, there is no guarantee that some car won't have all its updates filtered out. On the other hand, with separate items, if you set frequency limits on each, the Server applies a round-robin behavior.

Let me stress that even with one item per car there is no need for the client to explicitly subscribe to all cars.
The simplest thing to do is getting the list of cars from the Server as well, by using "two-level push". This is shown in our portfolio demo, which is similar, as you actually manage portfolios of cars.
This implies some work on the client side, to get the list of cars and subscribe to each car, but this is handled by Lightstreamer Web Client library, which supports two-level push directly, as the demo subscripion code shows.
Under the hood, all single subscriptions for each car still take place and this may be inefficient; but the figures involved should be manageable. Should scalability requirements come, a more complicated strategy could be devised.