[bf1942] Using sqlite with BF2 in Windows

[Andreas Fredriksson]

On 4/21/06, "Einar S. Idsø" <esi at itk.ntnu.no> wrote:

> However, the amount of traffic going between the server(s) and the
> manager will be minimal. We're talking about strings in the order of a
> couple of hundred bytes transmitted every few seconds. I would be very
> surprised if Win2k3 cannot handle that correctly on localhost?

You won't see any problems until you are under load and happen to
spawn a number of subsequent requests (naïve example: getting all
attributes of all players with separate method calls.)

If the server process is starved for too long, you could lose those packets.

> UDP has the great advantage that a datagram is clearly defined. There is
> no need to count bytes or otherwise figure out when a package ends -
> just send a message that is small enough to fit into one datagram, and
> you are home free. At least from the little I know about socket

Yes, but the in the case the message doesn't fit in an UDP package
additional logic similar to TCP will have to be written which will
hold packets that arrive out-of-order. This is what high-performance
game network stacks do. They use UDP because of latency improvements
and non-blocking behavior, but also spend time reassembling packets in
a sliding window to guarantee ordering of events and to be able to
force delivery of certain packages.

> cPickle is unfortunately not included, neither is marshal or any other
> serialising module that I can find. If I am going to have to write a
> message packer anyways, then I may just as well transmit the data as an
> xml-string from BF2. Or are you suggestion I make my own pickler? I
> suppose I could, but I am not sure it would be worth it the trouble.

I assume you could get by with a simple recursive pickler that just
works the dict and does a type switch, calling itself recursively on
demand. If you don't need reference cycles and other oddities in your
data structures this would be a reasonable approach. To get something
up and running quickly you could use something like this (psuedocode):

serialize(object, buffer): # buffer is some stream-like data structure
  for each (serializable) field f in the object's dict:
    buffer.write(type_repr(f)) # which maps to some unambiguous
descriptor for each type
    if f is a primitive field (int, float, string, boolean):
      serialize that simple type as a string
    else:
      buffer.write(len(f))
      if f is a list:
        for subfield in f: serialize(subfield, buffer)
      if f is a dict:
         for subk, subv in f:
            serialize(subk, buffer)
            serialize(subv, buffer)

For the basic data types this would probably be less than 50 lines of
code. One advantage with this approach is that you can implement the
peer in some other language (PHP, C# or Java come to mind for various
use cases). This code could indeed produce XML as well, but parsing
real XML is much more difficult than working with a binary or
structured text format.

// Andreas

--
Those who live by the sword get shot by those who don't.