I want to keep game logic decoupled from networking, so I have a net class that listens to game events that should be send to the remote peer.

When an event is received, I send this info to the remote peer.

When a packet is received, I generate an event and send to the game logic...loop!

Im producing and consuming forever, and the only way I see to stop this is making the game logic aware of both events and "remote events"..I dont like this..

How would you solve this?

The game logic is really raw right now, I dont have the concept of a "player 2" yet, Im just treating inputs and core mechanics..Input is also decoupled. I was expecting to have just an above layer treating players / scores stuff, and let the logic only with core stuff, trying to keep the concept of players out of the core mechanics, dunno if I will be able to do that, or if I should..

Perhaps I should include in the event data a player ID (or even a bool bRemote) instead of having another event? Then my net class checks if player ID is local or remote before generating an event, the game logic dont need to know about it..

Another thing Im thinking about, is not generating any even on the net class, instead, when I receive a packet Id call the game logic handler method that is called when the event is received...kinda intrusive, but I dont know if this is a problem.

Is the problem that, once you send a message, it comes back around, forever?

If so, I see a bunch of options:

1) You can timestamp events/messages, saying "this event is for time X." Deliver it at time X, and don't accept messages to re-deliver when the timestamp is "now" or in the past.

2) You can mark messages with a source -- "from network" messages would not get re-messaged.

3) You can intercept the messages to forward on the "send" operation instead of from the queue. Thus, the function that "normal objects" use to put a message into the queue also marks them for sending. The network receive function puts the messages into the queue in a different way, that doesn't re-queue them for sending.

4) You can give each object an ID, and mark messages with which object they're sourced for. Each object has a master on a particular host. Messages are only sent on the network for objects that are mastered on the sending machine.

You can also move away from message replication to state replication, which would be a bigger kind of change.
Which way you go depends heavily on what kind of game you're building in the end, and what your authority/rules model will be.