Re: [glob2-devel] Glob2 salvage proposal

[Andrew Sayers]

> Feel free to request any document you feel is missing. As I can't document 
> everything at once, I think the easiest thing is that you ask what you need 
> or think it will be most usefull. Do you have any format your prefer ? Would 
> you like doxygen documentation or do you prefer text files in doc/ or would 
> you like things on the wiki. I don't feel very comforable with the wiki right 
> now as it is much more difficult to add a user there than on savannah... does 
> anyone knows if there is a mod or something for pmwiki that makes it more 
> conveniant? If not, should we change our wiki engine?

If we're moving servers (still no response from icculus.org, by the
way), how about we let the people hosting us decide on the type of Wiki?
It would be one less demand we're putting on them.

> As you have probably all noticed, my salvage proposal put a big emphasis on 
> changing the network model. This is because it is the only part I really 
> don't know enough to fix/extend/modify. Furthermore, it is very complex 
> because of this NAT/firewall problem.

The NAT/firewall issue shouldn't add much complexity to a well
implemented protocol stack.  I'd be quite interested in tackling this
problem.  I've posted some thoughts on how the top level of the
network API might look - I wrote it last night, but it's not turned up
until just now, hence it not responding to your points.

>                                       Third, our current network model is 
> really difficult to manage: the synchronization requirement is indeed very 
> demanding (for instance, it prevents the use of float or double, because 
> their behaviours is not the same on different computers).

I noticed this when I was writing the iostream implementation.  I
thought about using XDR (http://www.faqs.org/rfcs/rfc1014.html), but
decided against it as I don't know how well it's supported on different
platforms.  If it's important that we be able to transfer floats, I can
rewrite the binary iostream code to use XDR - one of the nice things
about the iostream implementation is that doing so would be completely
transparent outside of the iostream code itself :)

The only other big synchronisation requirement I'm aware of is the need
for clients to agree on the random number generator they use, which
seems to be going OK (I was able to understand it without documentation,
and have cleaned it up a bit too).

> This said, I've the feeling you do not want too big changes, which is very 
> reasonable. Nevertheless, do you have any suggestion on what to do with this 
> network problem ?

Actually, I'm very keen on changing the network code, because I think
it's important that the orders be put in the sections of the program
they relate to (e.g. building orders in Building.h) so that people who
want to work on discrete sections of the code can do so.  It's just that
I'm not convinced that a client/server model would help - for every
problem it fixes, it seems to create an additional one.  Actually, I
found the synchronisation method quite a refreshing way of dealing with
the problems of lag and lack of a powerful central server.  As with much
of the Glob2 codebase, the theories are excellent, it's just the
implementation that needs work.

> Andrew, what is the state of maprewrite_branch ? If it is mostly usable, I'm 
> ready to merge it to HEAD and continue the development and the required 
> rewrites in HEAD. I agree that we need to clean things and that's ok for me 
> to break map format, if we do a very clean and easily extendable format this 
> time :-)

It's far from usable I'm afraid.  I've been rewriting things to use the
new I/O framework (which has allowed me to get rid of at least 3
different parsers), and will need to thoroughly test them all.  I've
also been playing with the order code, to come up with the ideas in my
other post.  As I've said above, I'd be happy to do a complete rewrite
of the network code - although it would put the date of any release back
even further, I think it'd be worth it to have a codebase that newcomers
can pick up and work with.

I think it's better that we look at the map rewrite as a branch for
long-term changes, and let people that want to fiddle with ideas on a
working system use the HEAD branch.  That said, I'm quite happy for
others to work on the map-rewrite branch, although I'll probably need to
improve my CVS etiquette if they do.

        - Andrew