Jump to content

  • Log In with Google      Sign In   
  • Create Account

#Actualjbadams

Posted 15 April 2014 - 02:16 AM

 

Other than to beware of concurrent edits (e.g. network thread adding to the queue while the processing thread is removing from the queue) yes, that can work quite well. The network is just a data transfer medium. You are right to want to keep it simple. Write data, read data, that's it.

 

The interesting part is what you do with that data inside the game.

 

Well, I'm locking the queues while I'm reading or writing to them. The current mechanism tries to;

 

Network thread --

Lock incoming queue and write to it, then unlock

Lock outgoing queue and send packages, then unlock

 

Game thread --

Lock outgoing thread and write to it, then unlock

Lock incoming queue and read from it, then unlock.

 

Just to minimize locking. Probably not perfect, but it works so far and I'm happy.

 

 

 

If any of you have any experience regarding entity-component-systems and how to integrate network to them easily while still keeping them flexible/extendable, the whole point of a entity-component-system, then please drop by in my other thread.

 

 

Looks good to me!

 

I have a full message/scheduling environment (called Flow) built around lazy type evaluation and the like a bit like AgentC describes in his answer to the other thread.

 

You can build one too if you like, no big deal to it. Also like that there is no distinction to networked or non-networked messages as all individual variables come with full type info (this means that yes bit compressed flags and small variables can take a lot of space - in which case you send a special binary field and compress them all into it) and if you as receiver cannot handle it you just don't. Simple. The approach of creating elaborate class hierarchies, special message container structures and the like is antiquated and quaint (in my opinion), but it is used by industry giants such as google, so it must be good for something :-)

: Restored post contents from history.


#6jbadams

Posted 13 April 2014 - 01:28 AM

 

Other than to beware of concurrent edits (e.g. network thread adding to the queue while the processing thread is removing from the queue) yes, that can work quite well. The network is just a data transfer medium. You are right to want to keep it simple. Write data, read data, that's it.

 

The interesting part is what you do with that data inside the game.

 

Well, I'm locking the queues while I'm reading or writing to them. The current mechanism tries to;

 

Network thread --

Lock incoming queue and write to it, then unlock

Lock outgoing queue and send packages, then unlock

 

Game thread --

Lock outgoing thread and write to it, then unlock

Lock incoming queue and read from it, then unlock.

 

Just to minimize locking. Probably not perfect, but it works so far and I'm happy.

 

 

 

If any of you have any experience regarding entity-component-systems and how to integrate network to them easily while still keeping them flexible/extendable, the whole point of a entity-component-system, then please drop by in my other thread.

 

 

Looks good to me!

 

I have a full message/scheduling environment (called Flow) built around lazy type evaluation and the like a bit like AgentC describes in his answer to the other thread.

 

You can build one too if you like, no big deal to it. Also like that there is no distinction to networked or non-networked messages as all individual variables come with full type info (this means that yes bit compressed flags and small variables can take a lot of space - in which case you send a special binary field and compress them all into it) and if you as receiver cannot handle it you just don't. Simple. The approach of creating elaborate class hierarchies, special message container structures and the like is antiquated and quaint (in my opinion), but it is used by industry giants such as google, so it must be good for something :-)

 

spinningcube

: Restored post contents from history.


#5spinningcube

Posted 12 April 2014 - 07:54 PM

.


#4spinningcube

Posted 20 March 2014 - 07:00 PM

 

Other than to beware of concurrent edits (e.g. network thread adding to the queue while the processing thread is removing from the queue) yes, that can work quite well. The network is just a data transfer medium. You are right to want to keep it simple. Write data, read data, that's it.

 

The interesting part is what you do with that data inside the game.

 

Well, I'm locking the queues while I'm reading or writing to them. The current mechanism tries to;

 

Network thread --

Lock incoming queue and write to it, then unlock

Lock outgoing queue and send packages, then unlock

 

Game thread --

Lock outgoing thread and write to it, then unlock

Lock incoming queue and read from it, then unlock.

 

Just to minimize locking. Probably not perfect, but it works so far and I'm happy.

 

 

 

If any of you have any experience regarding entity-component-systems and how to integrate network to them easily while still keeping them flexible/extendable, the whole point of a entity-component-system, then please drop by in my other thread.

 

 

Looks good to me!

 

I have a full message/scheduling environment (called Flow) built around lazy type evaluation and the like a bit like AgentC describes in his answer to the other thread.

 

You can build one too if you like, no big deal to it. Also like that there is no distinction to networked or non-networked messages as all individual variables come with full type info (this means that yes bit compressed flags and small variables can take a lot of space - in which case you send a special binary field and compress them all into it) and if you as receiver cannot handle it you just don't. Simple. The approach of creating elaborate class hierarchies, special message container structures and the like is antiquated and quaint (in my opinion), but it is used by industry giants such as google, so it must be good for something :-)

 

spinningcube


#3spinningcube

Posted 20 March 2014 - 06:56 PM

 

Other than to beware of concurrent edits (e.g. network thread adding to the queue while the processing thread is removing from the queue) yes, that can work quite well. The network is just a data transfer medium. You are right to want to keep it simple. Write data, read data, that's it.

 

The interesting part is what you do with that data inside the game.

 

Well, I'm locking the queues while I'm reading or writing to them. The current mechanism tries to;

 

Network thread --

Lock incoming queue and write to it, then unlock

Lock outgoing queue and send packages, then unlock

 

Game thread --

Lock outgoing thread and write to it, then unlock

Lock incoming queue and read from it, then unlock.

 

Just to minimize locking. Probably not perfect, but it works so far and I'm happy.

 

 

 

If any of you have any experience regarding entity-component-systems and how to integrate network to them easily while still keeping them flexible/extendable, the whole point of a entity-component-system, then please drop by in my other thread.

 

 

Looks good to me!

 

I have a full message/scheduling environment (called Flow) built around lazy type evaluation and the like a bit like AgentC describes in his answer to the other thread.

 

You can build one too if you like, no big deal to it. Also like that there is no distinction to networked or non-networked messages as all of them come with full type info and if you as receiver cannot handle it you just don't. Simple. The approach of creating elaborate class hierarchies, special message container structures and the like is antiquated and quaint (in my opinion), but it is used by industry giants such as google, so it must be good for something :-)

 

spinningcube


#2spinningcube

Posted 20 March 2014 - 06:55 PM

 

Other than to beware of concurrent edits (e.g. network thread adding to the queue while the processing thread is removing from the queue) yes, that can work quite well. The network is just a data transfer medium. You are right to want to keep it simple. Write data, read data, that's it.

 

The interesting part is what you do with that data inside the game.

 

Well, I'm locking the queues while I'm reading or writing to them. The current mechanism tries to;

 

Network thread --

Lock incoming queue and write to it, then unlock

Lock outgoing queue and send packages, then unlock

 

Game thread --

Lock outgoing thread and write to it, then unlock

Lock incoming queue and read from it, then unlock.

 

Just to minimize locking. Probably not perfect, but it works so far and I'm happy.

 

 

 

If any of you have any experience regarding entity-component-systems and how to integrate network to them easily while still keeping them flexible/extendable, the whole point of a entity-component-system, then please drop by in my other thread.

 

 

Looks good to me!

 

I have a full message/scheduling environment (called Flow) built around lazy type evaluation and the like a bit like AgentC describes in his answer to the other thread.

 

You can build one too if you like, no big deal to it. Also like that there is no distinction to networked or non-networked messages as all of them come with full type info and if you as receiver cannot handle it you just don't. Simple. The approach of creating elaborate class hierarchies, special message container structures and the like is antiquated and quaint (in my opinion), but is is used by industry giants such as google, so it must be good for something :-)

 

spinningcube


PARTNERS