[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Well...




On 17-Jun-99 Matt Slot wrote:
> Jan Ekholm <chakie@infa.abo.fi> writes:
>  > The way it looks now I think I have to abandon the 'Zombie' project. I see
>  > no use for it anymore and I definitely have seen no public interest
>  > whatsoever,
> 
> I've been meaning to send some feedback for a while. You have something
> working, which is more than most of the other network libraries I've seen.
> Here is a list of suggestions based on my cursory examination of the Zombie
> docs and APIs:

I completely agree here. I really do think Zombie is one of the best libraries
for network programming out there, although there is probably room for more
improvements.

I have personnally spent the last few weeks porting the OpenPlay library from
Apple to Linux (which is used by the Myth II game we are working on here at
Loki). This is yet another cross-platform-wannabe networking API, which was
designed primarily for Mac and Windows (now I have a mostly working
Unix port too).

The general problem when it comes to network programming is that there is no
established standard API, apart from rather low-level ones like BSD Sockets
(DirectPlay sucks). So almost everybody comes up with its own library that they
use for their own developments.

What we would need, and I think Zombie / PenguinNet fits here, is an open, free
complete and supported API. This does not help much for porting existing
programs that already use their own library/API/whatever, but we could try to
push developers to use this API in their own products. So in an ideal world all
networked programs rely on a clean and open base.

[...]
>   * You use C++, which means the low-level stuff should be easy to abstract
>     and port to another platform.

Right, and I think this should be a very desirable feature of Zombie if you
want to get more developers to use it. OpenPlay was used because it is
cross-platform, and in fact it has this concept of "network modules" (it's a C
API by the way, no classes), which have to be written on each platform (for
instance TCP/IP on Linux, there is even AppleTalk on Macs).

Maybe trying to abstract a little bit more Zombie so that it can be used with
other transport protocols, and ports to other platforms/modules should follow
with some advocacy and interest from developers (cool applications for the
existing version of Zombie would help too!).

The problem with having a C++ API is that it won't be used by C programs, but
anyway our goal here is more to set a standard for future programs than to help
porting existing programs (I'd love to be able to use Zombie here, but it just
does not fit for what we're doing: porting existing programs).

[...]
>  > [...] but apparently everyone wants to do networking 'their own'
>  > way. Well, that's the way it goes...
> 
> Because I've yet to find a network session library that meets my needs (and
> satisfies my technical side), I wrote my own:
> 
>   * Mundane utilities, like memory allocation, threads, and queues are
>     abstracted into a specific utility library
>   * The low level network API abstracts the platform networking (sockets,
>     OpenTransport, etc). It only worries about endpoints, addresses, and
>     producing/consuming queues of data.
>   * The high level session API tracks hosts in the session, exchanges data
>     between given hosts by ID (not address), tracks latency statistics, and
>     performs any other administrative tasks (name+logo, synchronized clock).
>   * Messages are either fast status updates (current position, orientiation,
>     pressed keys) and reliable state changes (changes to the world, captured
>     resources, new objects) -- not specifically tied to TCP or UDP.
>   * The application is responsible for maintaining the simulation on top of
>     the high-level API, sending status updates or state changes as necessary
>     to keep the world operating.
>   * The high level API is in C and only has about 20 calls.
>   * The library runs on MacOS, Windows, and UNIX.

Wow, that looks a lot like the OpenPlay library. Did you check it out ?
OpenPlay is covered by the APSL license, so it is somewhat Open-Source. ;)


---
Stephane Peter                          megastep@lokigames.com
Programmer
Loki Entertainment Software