Shannon V. OKeets
Posts: 22095
Joined: 5/19/2005 From: Honolulu, Hawaii Status: offline
|
quote:
ORIGINAL: Zorachus99 Sounds good, however what happens in the case of a missing team leader? The other thing that is concerning me is error handling in the case of players who drop network connection in a less than graceful fashion. IP addresses change, network cables get tripped over, routers crash, etc... Have you decided on ports and protcols to be used in Netplay? For all of us behind NAT, port forwarding may be neccessary if we have to host by IP. Though it might be more work, a mutual place for negotiating the connection between players may remove the need to deal with forwarding issues. Applications like Hamachi negotiate ad hoc VPN tunnels through NAT/PAT connections. The core of this capability is that 'almost always' a connection can be established outbound, however incoming connections need to be forwarded often by static rules that create vulnerabilities in the protection a router/firewall is designed to provide. Bypassing this issue will increase the technical knowledge needed by players to host a game. Well, I got your drift but I only understood about 1/4 of the terms you used. The MWIF structure for sending information is the simplest I could think of: an ASCII string, comma delimited. The first data field in the string is the code for the string type (which defines what the rest of the fields are) and subsequent parameters identify an entry # and transaction # for the game record log. Each event in the game that affects the "game state" generates a game record log entry (GRL). When several GRLs are interdependent they have a common transaction #. For example, if 3 german units overrun a USSR unit, then the movement of each German unit from hex to hex is a separate GRL and all their movements together, plus GRL for the destruction of the USSR unit, have the same transaction #. Transmission between players will be by entry if the entry is "stand alone", an isolated decision (e.g., who won the initiative die roll). Otherwise GRLs are grouped together and sent as a single Transaction. I intend to encrpyt/decrypt the transmissions eventually. Getting transmissions through firewalls is not something I know anything about. ------------------------- As for a missing team leader, there will be one team leader (Allied side) who is MasterMWIF and can assign a new team leader to the other side (Axis). If the game falls apart because the Allied Team Leader goes AWOL, well, ... I have no solution at the present. ------------------------- The entry # and transmission # design permits validating that a player has not 'missed' an entry #, and that linked entry #s are not processed until all the entry pieces have been received. I expect it to be used to bring players up-to-date who have stepped away from the game for whatever reason. Saved games store the last entry # they received, so by processing the GRLs, a game can be brought up-to-date rather easily. I also dream of being able to play the game backwards using the GRL entries. In database terms these are roll forward and roll backward transaction processing.
_____________________________
Steve Perfection is an elusive goal.
|