if the connection object uses the socket interface to keep connections alive, it should be the same socket the dispatcher is attached to.

That's a problem in the context of OO. You want the component to use its parent to transmit packets, that forms a circular hierarchical dependency that you don't really want.

Moving the transport layer (Transmitter + Receiver) into a component, flattens the hierarchy a bit. instead of having A(B(A)), you have A(B, C(B)).

If you have virtual interfaces on components like a connection, then a factory looks to be in order. You may have different types of connections (point to point connection, a connection to a broadcasting station like SourceTV, a service, ect...). As you may have different sorts of transport layers (WinSock, replay buffer, ect...).

How should the dispatcher be notified of connections being closed? I was thinking of checking for return values during dispatch.

Who's responsible for managing the lifetime of connections? Or in what container they should be stored and move to and from (pending, established, closed)? Would it be yet another class that manages connection states and validity (keep alives, connection handshake, disconnection handshake)? Would connections be autonomous, with say, an internal state machine that the dispatcher can monitor?

TBH, I'm not a fan of such over complication. Having a whole army of components, each micro-managing things. I'm not a fan of monolithic design either, but this looks to be going a bit too far for my liking.

if the connection object uses the socket interface to keep connections alive, it should be the same socket the dispatcher is attached to.

That's a problem in the context of OO. You want the component to use its parent to transmit packets, that forms a circular hierarchical dependency that you don't really want.

Moving the transport layer (Transmitter + Receiver) into a component, flattens the hierarchy a bit. instead of having A(B(A)), you have A(B, C(B)).

If you have virtual interfaces on components like a connection, then a factory looks to be in order. You may have different types of connections (point to point connection, a connection to a broadcasting station like SourceTV, a service, ect...). As you may have different sorts of transport layers (WinSock, replay buffer, ect...).

How should the dispatcher be notified of connections being closed? I was thinking of checking for return values during dispatch.

Who's responsible for managing the lifetime of connections? Or in what container they should be stored and move to and from (reserved, for parties, pending, established, closed)? Would it be yet another class that manages connection states and validity (keep alives, connection handshake, disconnection handshake)? Would connections be autonomous, with say, an internal state machine that the dispatcher can monitor?

TBH, I'm not a fan of such over complication. Having a whole army of components, each micro-managing things. I'm not a fan of monolithic design either, but this looks to be going a bit too far for my liking.

if the connection object uses the socket interface to keep connections alive, it should be the same socket the dispatcher is attached to.

That's a problem in the context of OO. You want the component to use its parent to transmit packets, that forms a circular hierarchical dependency that you don't really want.

Moving the transport (Transmitter + Receiver) flattens the hierarchy a bit. instead of having A(B(A)), you have A(B, C(B)).

If you have virtual interfaces on components like a connection, then a factory looks to be in order. You may have different types of connections (point to point connection, a connection to a broadcasting station like SourceTV, a service, ect...). As you may have different sorts of transport layers (WinSock, replay buffer, ect...).

How should the dispatcher be notified of connections being closed? I was thinking of checking for return values during dispatch.

Who's responsible for managing the lifetime of connections? Or in what container they should be stored and move to and from (reserved, for parties, pending, established, closed)? Would it be yet another class that manages connection states and validity (keep alives, connection handshake, disconnection handshake)? Would connections be autonomous, with say, an internal state machine that the dispatcher can monitor?

TBH, I'm not a fan of such over complication. Having a whole army of components, each micro-managing things. I'm not a fan of monolithic design either, but this looks to be going a bit too far for my liking.

<quote>if the connection object uses the socket interface to keep connections alive, it should be the same socket the dispatcher is attached to.</quote>
That's a problem in the context of OO. You want the component to use its parent to transmit packets, that forms a circular hierarchical dependency that you don't really want.

Moving the transport (Transmitter + Receiver) flattens the hierarchy a bit. instead of having A(B(A)), you have A(B, C(B)).

If you have virtual interfaces on components like a connection, then a factory looks to be in order. You may have different types of connections (point to point connection, a connection to a broadcasting station like SourceTV, a service, ect...). As you may have different sorts of transport layers (WinSock, replay buffer, ect...).

<quote>How should the dispatcher be notified of connections being closed? I was thinking of checking for return values during dispatch.</quote>
Who's responsible for managing the lifetime of connections? Or in what container they should be stored and move to and from (reserved, for parties, pending, established, closed)? Would it be yet another class that manages connection states and validity (keep alives, connection handshake, disconnection handshake)? Would connections be autonomous, with say, an internal state machine that the dispatcher can monitor?

TBH, I'm not a fan of such over complication. Having a whole army of components, each micro-managing things. I'm not a fan of monolithic design either, but this looks to be going a bit too far for my liking.