Restored from previous forum. Originally posted by tranquil.
Hi all!
Someone has made experiences with network games and synchronizeing them?
I want to code a BomberMan clone for Networking but dont know how to synchronize the games.
Should I use the UDP Protocol for gaming? Where is the difference between TCP/IP and UDP?
Blitz contains a special UDP and DirectPlay commandset, what would be better?
Any Ideas?
Mike
Tranquilizer/ Secretly!
Registred PureBasic User
Game Networking Protocol
-
BackupUser
- PureBasic Guru
- Posts: 16777133
- Joined: Tue Apr 22, 2003 7:42 pm
Restored from previous forum. Originally posted by fweil.
Hope this will help you to understand for your context :
TCP is connection oriented and UDP is not.
This means that TCP checks connection during the whole communication usually established by a client to a server. Note that there is no real client / server relationship but rather a caller and a responder. Each time one side sends something an acknowledge is sent by the other side to confirm good reception.
Connection oriented protocol means flow exchange.
UDP does not specify any check about the data received by any other side. The sender just sends and does not check. This means that if any destination is reached or not the sending process does not care about. The data exchange is blocks oriented.
Concerning any software application if you decide to build a UDP protocol based data exchange, you will consider a server sending information to clients and receiving information from clients, but you will not easily build a clients to clients solution.
Choosing TCP makes easier the process to make several clients work together.
This is mainly because synchronization is uneasy when using UDP : synchronize what from where ? UDP requires a reference machine somewhere that we should name 'server'.
Never forget that client and server words have no precise meaning, but think to the client / server model to understand how it may work.
On my own, I consider an up-to-date software application should better work and be easier to design using a full tcp protocol level making possible to not consider a client / server model but a clients / clients organization bringing closer to the peer to peer concept (each connected station have a private possible exchange with any other).
Because UDP brings back to client / server model, it helps if you set-up a multicast or broadcast exchange type (from one to many or one to all) but it is not secured and easy to synchronize for one to one exchanges.
Does your idea use a one to one or one to many concept ? Anyway tcp does not mean impossible multicast or broadcast. tcp is a higher level of protocol that secures application about the good delivery of information.
Giving you a simple view of this is that when we had only udp level, it was not impossible to raise Internet applications but only not possible to manage easily interactivity like forms. With tcp managing a Web page send containing a form to reply to is really easy.
...
Francois Weil
14, rue Douer
F64100 Bayonne
Hope this will help you to understand for your context :
TCP is connection oriented and UDP is not.
This means that TCP checks connection during the whole communication usually established by a client to a server. Note that there is no real client / server relationship but rather a caller and a responder. Each time one side sends something an acknowledge is sent by the other side to confirm good reception.
Connection oriented protocol means flow exchange.
UDP does not specify any check about the data received by any other side. The sender just sends and does not check. This means that if any destination is reached or not the sending process does not care about. The data exchange is blocks oriented.
Concerning any software application if you decide to build a UDP protocol based data exchange, you will consider a server sending information to clients and receiving information from clients, but you will not easily build a clients to clients solution.
Choosing TCP makes easier the process to make several clients work together.
This is mainly because synchronization is uneasy when using UDP : synchronize what from where ? UDP requires a reference machine somewhere that we should name 'server'.
Never forget that client and server words have no precise meaning, but think to the client / server model to understand how it may work.
On my own, I consider an up-to-date software application should better work and be easier to design using a full tcp protocol level making possible to not consider a client / server model but a clients / clients organization bringing closer to the peer to peer concept (each connected station have a private possible exchange with any other).
Because UDP brings back to client / server model, it helps if you set-up a multicast or broadcast exchange type (from one to many or one to all) but it is not secured and easy to synchronize for one to one exchanges.
Does your idea use a one to one or one to many concept ? Anyway tcp does not mean impossible multicast or broadcast. tcp is a higher level of protocol that secures application about the good delivery of information.
Giving you a simple view of this is that when we had only udp level, it was not impossible to raise Internet applications but only not possible to manage easily interactivity like forms. With tcp managing a Web page send containing a form to reply to is really easy.
...
Francois Weil
14, rue Douer
F64100 Bayonne
-
BackupUser
- PureBasic Guru
- Posts: 16777133
- Joined: Tue Apr 22, 2003 7:42 pm
Restored from previous forum. Originally posted by tranquil.
Hi!
Thanks for your detailed info about UDP. Now I know how it works and I think I will use TCP/IP for our game.
I think about a "one to all" concept. Need to take a look on it and need to make some experiments how it works best.
My only problem is how to send and receive the coordinates and actions of the player simultanious. But I think I would do it so:
After a player takes action I will send these information to the server for prozessing, send the datas back to all other clients and then refreshing the clients screens. But what should I do if I refresh the screen 50 times a second? I cant send 50 Packets a 1000 Bytes (only as an example) for 5 Players. Thats definately to much for a small ISDN line. Not everybody uses DSL or something else. Hm, not very easy.
Mike
Tranquilizer/ Secretly!
Registred PureBasic User
Hi!
Thanks for your detailed info about UDP. Now I know how it works and I think I will use TCP/IP for our game.
I think about a "one to all" concept. Need to take a look on it and need to make some experiments how it works best.
My only problem is how to send and receive the coordinates and actions of the player simultanious. But I think I would do it so:
After a player takes action I will send these information to the server for prozessing, send the datas back to all other clients and then refreshing the clients screens. But what should I do if I refresh the screen 50 times a second? I cant send 50 Packets a 1000 Bytes (only as an example) for 5 Players. Thats definately to much for a small ISDN line. Not everybody uses DSL or something else. Hm, not very easy.
Mike
Tranquilizer/ Secretly!
Registred PureBasic User
-
BackupUser
- PureBasic Guru
- Posts: 16777133
- Joined: Tue Apr 22, 2003 7:42 pm
Restored from previous forum. Originally posted by fweil.
...
First you have to make a model of what events are useful to others and what information can give an event representation on the GUI.
It is not so much different than classical communication apps except the refresh rate of information that you will require.
A tcp message has a minimum size, whatever is the content either it is empty. This minimum size is about 40 bytes.
If you send some information add their size to.
Then you will have a look on the required bandwidth which makes some KBytes using a phone or ISDN line (typically about 6K one way).
This will give you back the capacity you can manage.
But there is also another trick with it : whatever will be the bandwidth, you have to take the latency in account also. The latency is the time (average or realtime) that a message takes to go from sender to end user.
Using Internet is never realtime even if you feel sometimes so. Usually a message need 100ms to several seconds to reach its recipient.
This means you will certainly not design a 50 frames / s model but just update end-user interface 'as soon as possible'.
...
Francois Weil
14, rue Douer
F64100 Bayonne
...
First you have to make a model of what events are useful to others and what information can give an event representation on the GUI.
It is not so much different than classical communication apps except the refresh rate of information that you will require.
A tcp message has a minimum size, whatever is the content either it is empty. This minimum size is about 40 bytes.
If you send some information add their size to.
Then you will have a look on the required bandwidth which makes some KBytes using a phone or ISDN line (typically about 6K one way).
This will give you back the capacity you can manage.
But there is also another trick with it : whatever will be the bandwidth, you have to take the latency in account also. The latency is the time (average or realtime) that a message takes to go from sender to end user.
Using Internet is never realtime even if you feel sometimes so. Usually a message need 100ms to several seconds to reach its recipient.
This means you will certainly not design a 50 frames / s model but just update end-user interface 'as soon as possible'.
...
Francois Weil
14, rue Douer
F64100 Bayonne