| 1 | |
|---|
| 2 | |
|---|
| 3 | |
|---|
| 4 | |
|---|
| 5 | WORD OF WARNING: |
|---|
| 6 | ================ |
|---|
| 7 | - Allways keep the network_settings.conf file from the data repos up-to-date!! Its very important, that the user numbers are synchronized! |
|---|
| 8 | |
|---|
| 9 | |
|---|
| 10 | WORKING_STACK: |
|---|
| 11 | ============== |
|---|
| 12 | - removed compiler warnings in some modules |
|---|
| 13 | - totaly rework of the permission system |
|---|
| 14 | - introduced a new PERMISSION layer: PERMISSION_SERVER which gives the nearest server the authority to handle |
|---|
| 15 | |
|---|
| 16 | |
|---|
| 17 | UNSOLVED: |
|---|
| 18 | ========= |
|---|
| 19 | - the clients cant get its ip in the handleHandshakes without throwing sigseg |
|---|
| 20 | - MessageManager: proxy/server forward the messages always. Perhaps there is a case, where messages get forwarded forever if there is a loop in the network. think about it again. |
|---|
| 21 | - Permissions: Proxy Servers shouldn't be able to create new eneitites on the server |
|---|
| 22 | - the nick name must be handled new |
|---|
| 23 | |
|---|
| 24 | |
|---|
| 25 | |
|---|
| 26 | This readme just gives some hints for the general network programming: |
|---|
| 27 | |
|---|
| 28 | ARCHITECTURE: |
|---|
| 29 | The NetworkStream is in the center of this structure. |
|---|
| 30 | |
|---|
| 31 | |
|---|
| 32 | UserId: |
|---|
| 33 | ======= |
|---|
| 34 | containing the id of a user (==client). This id must be unique within a orxonox network its used especialy in the NetworkStream for node identification and also in the Synchronizeable base class for permissions checking (PERMISSION_OWNER) |
|---|
| 35 | |
|---|
| 36 | the connections belonging tu toe userId's are stored in the NetworkStream::peers std::map. As a keyvalue the userId's are used. Therefore the usage of this peers map is very delicate. Don't ever try to add anything you are not sure about the id stuff. |
|---|
| 37 | |
|---|
| 38 | There are some reserved id's, don't mess with them: |
|---|
| 39 | 0 : Master Server |
|---|
| 40 | 1 : First Proxy Server |
|---|
| 41 | 2 : Second Proxy Server |
|---|
| 42 | 3 : Third Proxy Server |
|---|
| 43 | 4 : Fourth Proxy Server |
|---|
| 44 | . |
|---|
| 45 | . |
|---|
| 46 | . |
|---|
| 47 | NET_MAX_PROXY The maximal number of proxy servers |
|---|
| 48 | NET_MAX... + 1 First Client |
|---|
| 49 | NET_MAX... + 2 Second Client |
|---|
| 50 | . |
|---|
| 51 | . |
|---|
| 52 | . |
|---|
| 53 | NET_MAX_CONNECTION Last client |
|---|
| 54 | |
|---|
| 55 | The proxy server ids are assigned as stated in the data/trunk/config/network_settings.conf, the first proxy server in the list gets the id NET_ID_PROXY_01 and so on. |
|---|
| 56 | |
|---|
| 57 | |
|---|
| 58 | The ids are created by the master/proxy servers. Each server receives an address space of 1000 nodes where it is able to assign nodes to. This address space could be extended quite easely, since we got plenty of numbers in 4bytes (integer) |
|---|
| 59 | |
|---|
| 60 | The handshake sync has always the uniqueId == userId. This is why there are some reserved uniqueIds |
|---|
| 61 | |
|---|
| 62 | |
|---|
| 63 | uniqueId: |
|---|
| 64 | ========= |
|---|
| 65 | uniqueId is an id (unique :D) for each synchronizeable to be identified in a network. the number space for uniqueIds goes from 0 to maxplayers - 1 |
|---|
| 66 | |
|---|
| 67 | The handshake sync has always the uniqueId == userId. This is why there are some reserved uniqueIds |
|---|
| 68 | |
|---|
| 69 | |
|---|
| 70 | permissions: |
|---|
| 71 | ============ |
|---|
| 72 | Each synchronizeable variable has some write permissions. this permission systems allows to manage which network nodes are able to write the variables. |
|---|
| 73 | PERMISSION_MASTER_SERVER : only the master server can write this variable |
|---|
| 74 | PERMISSION_PROXY_SERVER : only the proxy server can write this variable |
|---|
| 75 | PERMISSION_OWNER : only the owner can write this variable |
|---|
| 76 | PERMISSION_ALL : all clients can write this variable |
|---|
| 77 | |
|---|
| 78 | Only the master server should have the permission to create new WorldEntities and to add them to the game |
|---|
| 79 | |
|---|
| 80 | |
|---|
| 81 | |
|---|
| 82 | |
|---|
| 83 | NetworkStream PeerInfo list: (peers) |
|---|
| 84 | ===================================== |
|---|
| 85 | The network node with the offset 0 is always the server to which the client must connect to (in case there are connections to other hosts at the same time). |
|---|
| 86 | |
|---|
| 87 | |
|---|
| 88 | |
|---|
| 89 | MessageManager: |
|---|
| 90 | =============== |
|---|
| 91 | The message manager has special handling if its a master/proxy: the messages will simply be forwarded to the other server |
|---|
| 92 | |
|---|
| 93 | |
|---|
| 94 | Proxy Control: |
|---|
| 95 | ============== |
|---|
| 96 | The ProxyControl class manages the state of the network by exchanging state messages. |
|---|
