[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] SOC Proposal: Networking for Pygame
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.