fox-wamp/supervisor/README.md

Web Application Message Router/Server WAMP/MQTT

# demo easy start

## resource-lock.supervisord.ini
three clients that lock resource for the 5 second each, so the next able to lock the resource after the previous release it

- to start:
```shell
$ supervisord -c ./resource-lock.supervisord.ini
```

## masterfree.supervisord.ini
masterfree band queue work

- to start:
```shell
$ supervisord -c ./masterfree.supervisord.ini


```
# blueprint
Yes, I know about snowflake-id

DateTime + Segment + Offset + [ Shard * ProcessingStep ]

advanceId {segment, offset}
    advanceId.segment - nearly random string value
    advanceId.offset - offset inside the segment

entry
    When message arrived, unique advance-id is created. Roundrobin creates partition-id. With that destination partition id is generated by round-robin. The message and all messages comming after that are signed by that advance-id and sequence number. The BEGIN_ADVANCE_SEGMENT is sent to all sync hosts and ndb-storages. Messages bodies are sent to all corresponding destination storage hosts with KEEP_ADVANCE_HISTORY message.

    at TRIM_ADVANCE_SEGMENT message the entry collects votes from storage copies. when TRIM_ADVANCE_SEGMENT elected the advance-segment is completed and ADVANCE_SEGMENT_OVER message is sent to destination storage host. New advance-segment will be generated at the next inbound message.

    for next advance id all not resolved items are sent to the next shard in creation order. that must keep inbound order when shard is changed.

    advance-segment-resolved message arrived when advance-id become permanent identifier. At that time entry able to send ACK message for messages with permanent id.

ndb-storage
    when BEGIN_ADVANCE_SEGMENT arrived, the TRIM_ADVANCE_SEGMENT message is generated immidiatelly to terminate segment at entry. arriving inbound messages in KEEP_ADVANCE_HISTORY are stored temporary with advance-id marker. when advance-segment-resolved arrived the temporary storage is moved to permanent.

    ADVANCE_SEGMENT_OVER event starts permanent id election procedure

sync
    the sync cluster is responsible to transform nearly random advance-id to monotonic id.


    entry                        ndb                          stage one                         stage two

        BEGIN_ADVANCE_SEGMENT ->

        KEEP_ADVANCE_HISTORY  ->

        <- TRIM_ADVANCE_SEGMENT * each ndb
        [vote to take network lag for segment]

        ADVANCE_SEGMENT_OVER ->

                                            GENERATE_DRAFT -> generate mew time+genId for tmp-id
                                                        send to next sync stage
                                                        
                                                    +---- VOTE
                                                    |        take low _in_vouter_ time+genId
                                                    |        for tmp-id send to final
                                                    |        sync stage
                                                    +->  PICK_CHALLENGER ->
                                                        challenger id is generated

                                                        <-> VOTE <->
                                                            two sync units generates draft id,
                                                            pair of lower is elected

                                                    ELECT_SEGMENT ->

                                                                                                VOTE MAX / StageTwoTask
                                                                                                

    -> ADVANCE_SEGMENT_RESOLVED