Jump to content

  • Log In with Google      Sign In   
  • Create Account

#Actualfrob

Posted 01 March 2014 - 03:17 AM

A1 and A2 have the same answers. You need to build meshes between the machines and relay the messages yourself. You can build fully-connected meshes where everyone talks to everyone, you can build partially connected meshes where some people talk to other people and they need to carefully relay meshes to those they connect, you can build publicly-visible repeaters so that people can fake a fully-connected mesh, you can implement a star where one machine is designated the server and everyone must have connectivity to it, or just about any other layout you can imagine. The logical topology of a network does not need to match its physical topology. Depending on your logical topology you might be able to reduce bandwidth requirements by merging messages if you know they share a communication route.

A3 is pretty fun. Yes, you can mix TCP, UDP, and other protocols within a single application.

Many beginners write their code based on having a single connection between machines.

While it is certainly possible to write code that way, nothing prevents you from making multiple connections.

As a simple example, many games have voice chat and implement the feature by simply dropping in a 3rd party voice chat library. That library creates its own UDP connections, builds its own mesh, and otherwise operates independently of the game's communication system. As another simple example, I can open up lots of instances of a web browser, or lots of tabs, each one connecting to the same server on separate connections.

If your game design works well by having a TCP connection as well as a UDP connection, that is certainly an option. If your design is such that you have multiple independent communication meshes, you can have a connection for each one. The thing that immediately jumps to mind is file transfers; you can make one connection per file, much like FTP, so that you effectively have a launcher connection and several individual worker connections. You might have multiple web connections, multiple telnet sessions, multiple SQL server connections, or combinations of all of them at once.


If you want to establish multiple connection channels while ensuring that connectivity remains consistent, build a protocol that establishes reliable UDP. You can also find existing packages that do this. Basically they set up a protocol with their own headers attached to packets, and the added headers allow for sub-channels. They can then write some custom protocol code that marks if the sub-channel must be reliable or not, and for reliable channels implement their own system of sliding windows, ACKs and NAKs, and all the other necessary pieces so they can retransmit the reliable sub-channels while handling unreliable sub-channels in a regular UDP manner.

: Typos. :(


#1frob

Posted 27 February 2014 - 11:42 PM

A1 and A2 have the same answers. You need to build meshes between the machines and relay the messages yourself. You can build fully-connected messages where everyone talks to everyone, you can build partially connected meshes where some people talk to other people and they need to carefully relay meshes to those they connect, you can build publicly-visible repeaters so that people can fake a fully-connected mesh, you can implement a star where one machine is designated the server and everyone must have connectivity to it, or just about any other layout you can imagine. The logical topology of a network does not need to match its physical topology. Depending on your logical topology you might be able to reduce bandwidth requirements by merging messages if you know they share a communication route.

A3 is pretty fun. Yes, you can mix TCP, UDP, and other protocols within a single application.

Many beginners write their code based on having a single connection between machines.

While it is certainly possible to write code that way, nothing prevents you from making multiple connections. As a simple example, many games have voice chat and implement the feature by simply dropping in a 3rd party voice chat library. That library creates its own UDP connections, builds its own mesh, and otherwise operates independently of the game's communication system.

If your game design works well by having a TCP connection as well as a UDP connection, that is certainly an option. If your design is such that you have multiple independent communication meshes, you can have a connection for each one. The thing that immediately jumps to mind is file transfers; you can make one connection per file, much like FTP, so that you effectively have a launcher connection and several individual worker connections. You might also have multiple web connections, multiple telnet sessions, multiple SQL server connections, or combinations of all of them at once.


If you want to establish multiple connection channels while ensuring that connectivity remains consistent, build a protocol that establishes reliable UDP. You can also find existing packages that do this. Basically they set up a protocol with their own headers attached to packets, and the added headers allow for sub-channels. They can then write some custom protocol code that marks if the sub-channel must be reliable or not, and for reliable channels implement their own system of sliding windows, ACKs and NAKs, and all the other necessary pieces so they can retransmit the reliable sub-channels while handling unreliable sub-channels in a regular UDP manner.

PARTNERS