I am sorting things for writing down my first paper on some special fast network technology.
Therefore there will be used several techniques for different special problems coming up when making a game capable for networking.
Goal is to make a responsible system for various server and client work on the network.
As this also is a problem of security i really have no idea on license and all this stuff.
I want to make this system even fast as secure.
Data send through the net has to be truly that whats needed and as i want to show u later this is not the easy question it looks like first.
I told Mojo small parts of this idea but i cannot get in this before writing my test on friday.
But when i found this area i had to tell u all about theese plans.
I know DarkFrog is working on some network system too but i don't know how it's build.
I even will look in this after this test, looking how he soluted things his way.
I think the first paper will be about 10 - 20 pages bringing up basics on the problems and the solutions i found out till now.
Hope to get auditory
Cream
Hey Cream,
Check out javagamenetworking.dev.java.net which is my abstract networking API and you can check out odenetworking.dev.java.net (when it’s finalized the approval) and get from CVS the work I’ve done on this. It’s really pretty powerful and I’m currently still working on ON as it needs a lot of testing and tweaking to really be useful, but take a look at the concepts as based on my studies thus far this is by far the fastest and most reliable way to do networking. I haven’t determined yet about the whole “blast to the past lagging” concepts or if it’s even viable, but other than that it’s pretty close.
JGN is completed though and you can download binaries and/or source from the site.
Good luck,
darkfrog
thats one point
before writing any line i want to write down a complete concept on how a server has to manage his data and how the correct information is brought to the server as fast as possible.
And in fact, what is the right information.
Next is this security thing.
What is a client able to do normally without let him get the chance to manipulate servers data.
Things he has to tell the server are commands like "Left" or "Right", not "Go straight forward through the mall straight up the stairs and turn by 180
Well, the security aspects are something I spent a great deal of time considering how to handle and in the end I came up with the best solution: push it off onto the implementing game. 
Realistically any game will have its own rules about what is allowed and what is not. However, you are referring to a user action architecture and after researching this I've decided it's a bad idea. That is how you run the risk of losing synchronization between client and server and never able to get it back. The best way I've been able to determine is for the client to send down Synchronization and Physics messages. These tell position, rotation, etc. information and the current physics applied. The benefit of this is that at any given point in time this will fully synchronize the server with the client or vice-versa. Now the problem of security here is much broader as a rogue client could just say, "Well, I want to be over there, so I'll just say I'm there". This is where the API comes in. In the API you have to implement an abstract method that receives the synchronization and physics messages and validates that they should be allowed. A typical client would probably validate the servers currently understood position of that object and determine whether enough time has passed since the last update whether it is feasable that they should be able to be where they say they should be. If not it can deny it and the next time the server sends a synchronization event to the client the client then would be updated to then be correct with the server and all other clients again.
The problem with a comman system of "Move Forward" is if you are lagged this will execute the action in a different time and/or location on the server and corresponding clients. You will continue to get further out of sync with every movement made.
Synchronization and Physics messages seem to be the most logical and most reliable way to go since even if they don't receive a message it doesn't really matter because although they'll be out of sync for that iteration they will be sync'd back up the next time a message is received by it for that object.
There is actually a lot more to this, but that should give you a good basis for what I've designed.
darkfrog
WHua :-o what did i done now
I have begun to write down some sort of specification this Network system shoud implement
As i have really much input i am still on writing in the information there.
This name is not THE NAME.
It's just because i need a flag under which i can begin so if there are more to help and good ideas i will also change this ^^
It is very much, at now i have 61 pages and i am still on the descritpion of different technologies and even dive into real time decisions of the NASA.
Many pages are copied from its original content implementing the original url.
As there is bundled true information i won't reinvent the wheel and tell its mine.
It's all not mine, i am just sorting.
So i will show u now ver. 0
This is nothing ready, i hope u will give me some reactions on all of this.
Thx Cream
http://yaska.cybton.com/SNOGL.pdf
if theres any help i am grateful, by means beginning at the correct spelling and ending by worthy information which can be added
This is my second warning on this, but I'll state it again anyway.
You are making a drastic mistake by sending movement commands instead of synchronization since the movement commands in ALL cases will destroy synchronization between server and client. Further, for bandwidth reasons it's a bad idea to send a command every time a key is pressed for obvious reasons. Finally, even if you were not dealing with lag (which realistically is an impossibility even on a local network) you would have serious synchronization problems if there was any point at which a command from the client doesn't make it to the server. They would be forever out of sync because there is no validation that the server thinks the object is in the same location or state as the client does. This is a terrible architectural dilema that you're going to have to work out.
Besides, you make reference to documents in your PDF that say quite the opposite to the way you are architecting this.
Well, that was my blundt response…no offense intended I just want you to realize the problems in this system. Also, I just skimmed your PDF but I believe you were originally planning on doing TCP Socket connectivity and I'd like to restate that this is a very bad idea as well. UDP is the only real option for a real-time networking environment.
darkfrog
as it is meant to be connection types seem to differ in the way they want to handle the system.
i am also looking forward to udp things but at now its not clear where i want to go i think
i wont send data every time a key is pressed, i want to make the system able to look itself up if data has changed dramatically to be updated.
I am really wondering where u can find the opportunities in this pdf, i know that it touches different fields but i don't see great conflicts in between and as u can see all of theese articles tell u that it is most important to be clear what and how data is sended through the net.
Sorry, I think you're still going about this all wrong. What you are trying to get to is half-way of what I am implementing in ODENetworking which is synchronization and physics messages. The synchronization tells the positional information and the physics message tells in what ways forces are applied to it. This is a much better way since then the client can deal with the result of that information in the physics engine and it keeps the client from having to maintain anything special for the networking aspect.
darkfrog
i think specialization on that field is the only truth for stable networks with many players
this all will not really consider u when only 4 or 5 people play that game
but when there are hundreds and more your synchronization thing gets to its limits but for the beginning lets see what both will make and don't say thats bad ^^
i know our opinions are quite opposite but i also dont say your work is for trash ^^
i only think it will not work on greater networks
to handle all this i will describe some kind of AI which will help this system to work
so theres a special AI in this network only for sorting all of this
I'm saying you're going about this the wrong way because you are. I've done enough in networking to know exactly what will happen with the way you are developing it.
To your point on larger networks that is in fact the major point I have addressed. The networking API I've written should scale very well no matter how large or small the network.
I'm not trying to say mine is great and yours is crap…I'm just trying to explain to you were you need to re-think your design. I've got a lot of years of experience and I'm not basing this on opinion, I'm basing it on absolute truth…such a thing does exist. 
darkfrog
hehe i did not do any design till now
i am still sorting stuff
what would be the best approach for creating an rts when send realtime information for each unit is highly inefficient. From what i have seen most professional companies use a method where events are created. Sent to each client and told to execute as a specific time in the future.
ex.)
1.) Player 1 says move forward, this is recorded at the 100th logical frame (im guessing)
2.) the command is sent to all players and told be executed during the 110th logical frame
3.) At the 110th logical frame, all computers execute the event including Player 1
This is why i am using a fixedLogicalRate for my game and also messages are sent to each keeping tabs on whether everyone is keeping up.
I'm not sure how else this could be done.
communicating only through events of actions(like start, stop turn etc) is a really bad thing, and I would say that your “bad sample” is the good one and the “good sample” is the bad one. we’ve used the “only send buttons” technique in some games and it’s an endless fight of synchronization. when one person lags behind, everyone else has to rewind to the time the button should have been executed, execute it, and the forward themselves back to the real time. otherwise the next input from that user will be completely irrelevant(if not doing the rotate left first, the rotate right will take the laggy user to the wrong position).
using the fps-style version of sending position, direction, speed etc does not have to result in taking up more bandwidth since it can be used in conjunction with “dead reckoning”, which in it’s optimum won’t send more than the “send actions” version.
here’s a nice article on x-wing tie fighter, one of the few games that actually used the “send keypresses” version, about the problems the had with doing that…
http://www.gamasutra.com/features/19990903/lincroft_01.htm
and here’s a nice article on dead reckining:
http://www.gamasutra.com/features/19970919/aronson_01.htm
Go to http://opentnl.org and read the Torque networking documentation (if it's there) - it's a good system and worth the read.
MrCoder,
You mean JGN isn't your favorite networking library? My feelings are hurt… :-p
darkfrog
it will surely change if/when I get time to use it!
Okay, well I guess I'll let it pass this time. :-p
darkfrog