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

[Br'fin <br...@ma...>]

On Wednesday, January 22, 2003, at 09:24  AM, Woody Zenfell, III wrote:

> 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.

Shows you what I know. I honestly haven't really *looked* at Marathon's 
networking code and organization. And what I did for A1 doesn't count, 
because I still wasn't looking at the code, but just connecting things 
together cluelessly :)

> 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 cleanliness thing to my thinking. I admit in the case of 
networking I'm less picky about having CLowLevelNetworking and 
CLowLevelNetworkingSDL be separate classes. But the stuff including 
CLowLevelNetworking.h shouldn't also need to include "SDL_Networking" 
anywhere along the way either.

Basically, given what I've said before regarding other modules, I 
*should* hold the networking platform elements to the same standards. 
Even if there's only ever going to be one implementation.

> 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.

If each layer did everything that a given app needed from it, we 
wouldn't need more layers. OpenTransport wasn't about when M2 
networking was setup. Sockets weren't the only networking target for 
the initial networking either.

I admit for AM we have simpler networking targets. Internet based 
sockets. I would suspect that our low level network layer would 
actually be simplifying some of the SDL stuff. (One of our calls 
translates to one or more SDL calls for instance, or the same call but 
with out all the flexibility that the initial SDL call needed to allow)

> 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.)

Yes. I just haven't had the heart to cvs remove any of the network 
files yet.

> 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.)

Flexible hooks are good, yes. :)

Scheduling, I agree, is still a hazy issue. I haven't yet researched 
what threads are necessary and what the requirements around them may be 
for different platforms.

Classic was ok with a VBL timer task for input and letting the main 
thread handle rendering. (And I admit I don't know where networking 
fits in here!)

Carbon, on the other hand, would much rather have the OS Event loop in 
the input thread and have the main game thread with rendering as the 
separate entity.

> [snipped, regarding action flags]
Yes, you're probably right here. I don't have a good grasp on when 
certain game internal structures are going to be redone as classes. It 
may be on an as needed basis.

> 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.

Dialogs I've not done enough thinking on. But I now have some thoughts. 
I'll try and get to them in another email later today.

>
> 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
>
Style-wise I'm working to stay consistent with the current Marathon 
code. Failing that possibility where there's new code features, I'm 
inclined to go with ISample interfaces and CSample classes. And if 
casting needs to be done, try and use the C++ style casts.

Alright on the code if it helps you think. Some documentation would be 
nice (And Yes, i need to get on my own case regarding this too :) )

-Jeremy Parsons