The Server class provides the following methods :

::start

::pause

::resume

and

::stop.

When writing a code that interacts with the SCM you usually provide 4 entry points that correspond to the 4 possible actions : start, stop, resume and pause.

When wrapping the ::stat method in an entry point function, makje sure to use the blocking version ie setthe startInSeparateThread parameter to false.

Sometimes, changes mean that past Dashboard versions can not talk to new Push Framework versions. The opposite is also true.

A rule has been made to make the Dashboard depend on Push Framework onward.

When the Dashboard connects, it send a request containing the supported protocol version. Your Push Framework-based server reads the version and makes the decision on whether this is supported or not. In the negative, the server refuses the connections and your Dashboard displays a message prompting you to use a newer version of the Dashboard.

The Dashboard recent version i always available in the “Downloads” section of the website.

If you use Push Framework, you may wonder about the best way how to use database connections and queries operations.

We know that for the 90% of cases it is not possible to use one database server connection concurrently without conflicts.

Thus one immediate solution would be to initialize a connection for each thread and use it whenever required. This would be possible if Push Framework give you access to “per workers” contexts. However the librray does not give you access to the moment when a worker thread is started and when it is accessing the last bit of code before being destructed.

By the way, PushFramework::Service contructors execute on the main thread of your program process.

The best way to manage database connections is to use a shared and safe pool of connections.  You can initialize the pool at server startup and you retrieve borrow anddispose connections in Service::handle without the fear of conflicts that can result from making concurrent queries for a same connection.

1. Create a Push Framework based server that initializes a number of broadcasting channel. Choose different values for teh priority and quota number

2. Channel should not require explicit subscription. Design a client program that connects, receives server data and reports statistics , mainly the percentage of received data in each broadcasting channel.

3. Start your server and launch another thread that makes sure that all broadcasting channels remain full.

4. After a certain duration, stop the client program (not the server to get accurate report). When client connectiuon stopped, values should be displayed before the process ends.

The following rules yield themselves :

1. If you created a channel A and another channel B such that priority(A) > priority(B) then if channels fill rate is > than sending rate, then client will only receive packets belonging to channel A.

2. If you created a channel A and a channel B with a same priority number the if the fill rate of both A and B is > than the sending rate, then we count a number of received packets that is proportional to the channel quota number.

This behavior is explained more on This PDF :

http://www.pushframework.com/wp-content/uploads/2010/12/Data-broadcast-in-Push-Framework.pdf

UPDATE :

This validation idea was implemented in this article : http://www.pushframework.com/?page_id=435

However I am not sure if IOCP is available on all OSs.

Considering the lack of time and the very fact that unfortunately I never touched other operating systems, I can’t promise to port myself this library in any time soon.

Never make the assumption that Service::handle method can only be executed by a single thread at once. Even for the one Service object, two threads may act on its same ::handle method.

The two function used to manipulate client keys/structures :

ClientFactory::getClient

ClientFactory::returnClient

are not object locks. They merely inc/dec reference counter for each Client object you desire to work with, in order to detect the safe moment of disposal when a Client is disconnected.

Thus there should be no thread contention. Thread contention happens for the very short moments when you try to push data to a same Client object from more than one thread at a same time.

Having said that, it is thus the developer responsibilty to implement synchronization  whenever that is needed for the new data structures that are added to the program code.

By default, evry connection request is accepted. However,  the developer get the chance to check if the connection is a legitemate client before allocating resources and attaching the connection to a Client object.

First, the developer can force the framework to send an outgoing packet before the receiving of any request. The decision on whether to accept the client can then be made when the first request is received.

The ClientFactory class provides the following virtual methods :

::onNewConnection

::onFirstRequest

Strongest authentification mechanisms can be achieved by devising a dynamic response in ::onNewConnection then expecting a correct answer in the first request received.

Example :

in ::onNewConnection :

generate a random number x.  calculate y=F(x) then save y into the lpContext parameter and send x to the client.

and in ::onFirstRequest:

read the received y’, pull y from the lpContext parameter and compare the two numbers. If they are equal, accept the client.