Re: [Alephmodular-devel] Networking module thoughts (was re: Random musings online and thoughts towards 0.4)

[Woody Z. I. <woo...@sb...>]

It sounds like what you're picturing mimics A1's current layering etc., 
we should just make the various interfaces more explicit (group related 
functions in a class, e.g.).  That's fine with me.  :)  I've been 
wanting to clean up A1's network subsystem code anyway; maybe I should 
just do this in the context of A1 at the moment, and AM can of course 
use the code as well.

I'm concerned about what you mean by "SDL should be just another 
platform"; currently all A1 platforms use SDL_net for their networking 
(though the Classic version also uses Open Transport directly for one 
module).  I assume what you mean is that if somebody wanted to write an 
all-OT implementation (though why they would want to do that when the 
cross-platform code works fine is beyond me) that they would be able to 
drop it in with a minimum of fuss.  That's already the case essentially, 
the only sticky bit is in the handling of addresses (which should be 
relatively straightforward to take care of).

It's a bit funny to think that interfaces like sockets and XTI (the 
basis for Open Transport) are wrappers that try to hide the details of 
an implementation - and then we're wrapping those in SDL_net to hide the 
details - and then we're wrapping SDL_net to hide the details.  But I 
suppose each layer buys us something.

It's my understanding that the network_modem and AppleTalk stuff should 
be treated as dead code at the moment - yes?  (I mean in AM; I already 
consider it dead in A1 and plan to strip it out Real Soon Now.)

The interesting questions in my mind all have to do with scheduling, 
which hasn't really come up yet.  I'll see what I can think up.  I mean, 
different schemes are going to have different scheduling requirements - 
like, the ring scheme requires that the machine drop everything and get 
the ring packet passed on ASAP when one arrives; in a star scheme, the 
incoming data is only needed just before render time, for doing updates 
(whoops, need to talk some more about your overall architecture, I just 
remembered) and so the incoming data can be handled in the main thread.  
Well probably the simplest option is to provide the hooks for both 
schemes, and have a given protocol only use whichever it needs.  (i.e. 
in a star scheme there's no "packet listener" associated with the UDP 
socket, so the star code doesn't use whatever interface lets it 
associate one; in a ring scheme there's no special processing to do just 
before update, so NetworkStuff->AboutToUpdate() (called by the update 
routine) doesn't do anything.  That sort of thing.)

I think one of the most important things, looking forward, is to further 
abstract the action_flags - have a class for them that can return info 
about whether the user is pressing the second trigger, etc., can set the 
values for a given action_flag as to whether the user is pressing his 
action key etc., and which knows how to pack/unpack them (possibly using 
different schemes for films vs. network packets) and copy them.  I 
suppose the same code module should probably be responsible for handling 
queues of action_flags.  This way we can leave our options open in the 
future - using something other than a 32-bit word to store action_flags, 
adding new kinds of input, etc. - and making the change shouldn't 
require significant alterations outside the action_flags code itself.

I consider the netgame-related dialogs to be outside the network code, 
though clearly they need to communicate.  [The dialogs being considered 
separate] is probably a Good Thing, because at my last count we still 
vigorously disagreed on the best design for dialog-related code, what 
with me advocating a more flexible, more modular, more "layered" 
approach that lets developers share code.  (This being the high-level 
dialog logic/low-level system widget implementation split; nothing to do 
with using SDL as the default dialog system or not.  I have made several 
arguments for this scheme and have pointed to its successful use in 
practice (the A1 netgame dialogs), but have heard no reason as to why we 
would want to separate the dialogs by platform at a high level and thus 
*force* every platform to provide its own implementation of the same 
basic logic, instead of letting them share if they wish to but letting 
them diverge if they find they must.)

Anyway, I'll see what I can come up with with regard to networking and 
input.

Do we have any consistent style guidelines with regard to naming 
classes, methods, data members, locals, file-global (static) storage, 
class methods, globals, class (static) storage, ordinary functions, 
files, etc.?  Placement of braces?  Layout of a function's formal 
parameters at the function definition?  etc.  I figure the clearest way 
to express my design is going to be to write code, and the code may turn 
out to be useful to boot.  :)

Woody


On Wednesday, January 22, 2003, at 07:19  AM, Br'fin wrote:

> At the moment, the things that come to mind are
> 	
> 	Modular networking
> 		So things don't care if they are talking with CNetworkRing or 
> CNetworkStar
> 	Modular layers
> 		So one object is doing the actual interfacing with the 
> network libs and a
> 		higher level is dealing with the actual data being sent back 
> and forth. I should say 		that SDL should be treated like 
> another platform even down here. (I'm not so sure I
> 		have the heart for it down here in networking, but I should ;) )
> 	Separation of GUI and implementation
> 		I know, I know, this is an ill defined area. But network 
> setup should probably
> 		be of the form GUI->DoNetworkGatherDialog(..., networkGatherOptions)
> 		If we can bump off the GUI class for another intermediary 
> class, that's even better.
> 		this->networkConfiguration->GetNetworkGatherOptions(...) Thus letting
> 		configuration come more transparently from a file or other 
> source as well.
> 	Replays need to be maintained
> 		Even if the server is driving everything, I guess the local 
> machine still needs
> 		the action flags for its own personal replay recording.
>
> As for how closely you accommodate existing code? What is defined and 
> documented now is most likely going to stay as is for a good long 
> while. Unless there is a decent way to have networking overall be 
> flexible enough to affect the action flags like it does now, and later 
> be driving a shallow game core that mostly updates the animation's game 
> states, you're probably going to be locked into one or another method 
> of networking and driving the game.