Re: [pygame] SOC Proposal: Networking for Pygame

[Bryce Allen <pygame@xxxxxxxxxx>]

I think what everyone really wants is a simple to use yet powerful API. I 
think buffering should definitely be done in the network layer. Reconnection 
and lossy sending are also a great ideas, but I'm not sure if I'd implement 
them in the same protocol class, or create new classes for reconnection and 
lossy sending. In other words, in order to have the ability to do lossy 
sends, you'd have to specify that you need it when you initialize the network 
layer.

I also think it would be great to handle NAT and firewall issues, even if it's 
just to help give feedback to the user. Certainly this should be in the 
documentation, and should be given more thought.

I think it will be difficult to be all things to all people. I would like to 
provide a simple to use standard networking module that would work for most 
games, but still make the API useful for people with stronger demands who 
need to customize. Having a hierarchy of protocol classes is currently my 
best idea for doing this.

Thanks for the feedback everyone. I will update my proposal tomorrow to 
address the points you mentioned, and add personal information and a time 
line. I will have intermittent network access, as I will be traveling by 
plane, but I will have lots of time to work on the proposal, and I will try 
to check back with this list.

Good luck Frode! Hope we can find a mentor for this project.

-Bryce


On Sunday 07 May 2006 20:59, Brian Fisher wrote:
> On 5/7/06, Rene Dudfield <renesd@xxxxxxxxx> wrote:
> > But should lossy data be considered for simple networking?  If so I
> > think giving the send method, or argument a lossy flag would be good.
> > So that the game can tell networking if it cares about this type of
> > data.  Just using a udp 'connection' would be probably be enough.
>
> I think the answer to including "lossy" considerations to "simple
> networking" depends on what "simple" means. I get the impression from
> the wiki page that the project proposal is asking primarily for
> something simple technically and in terms of features (i.e. a thin
> wrapper of underlying ablities). But if "simple" referred only to the
> ease of use for client code, it would mean a very different design, in
> my opinion.
>
> For a "simple to use" api, I definitely think letting a game specify
> "lossiness" of data sent should be part of simple networking, In
> particular I would want to be able to specify whether an individual
> packet is guaranteed, and whether it is ordered as 2 seperate flags.
> The newer versions of DirectPlay (component of DirectX) allow you to
> do that, and it really can make it simpler and clearer. While making
> an API let the user pick between UDP (not guaranteed & not ordered)
> and TCP (guaranteed and ordered) is simple technically, it's just a
> long way around for a user to try and get things to work as close as
> possible to the way they want them to work.