[bf1942] Using sqlite with BF2 in Windows

["Einar S. Idsø"]

Andreas Fredriksson wrote:
> Using UDP this way has two serious drawbacks: fixed upper message
> length and non-guaranteed delivery. UDP on localhost isn't watertight
> on the NT kernel, the per-process buffers are fairly small, if memory
> serves. If you happen to trigger a cascade of packets within one
> timeslice of your sender process, you could end up losing a great deal
> of them because the other process hasn't got a chance to drain the
> packet pool until it's scheduled again. Linux is much better.

This is very interesting indeed. We have been using an announcer-module
for months now without any problems. The module listens on a UDP socket
and receives strings to send out as server messages from a centrally
located broadcaster-program, also written in Python. There have been no
problems with it, but we only have experience with Linux. The transition
to Windows is proving more and more painful by the day. ;)

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?

> TCP on the other hand is tricky to use correctly in non-blocking mode.
> However, if you're anticipating a low number of connections (as I did
> in the RCON module), just go ahead and poll the socket now and then
> for traffic. You can't use select(), because that would block the
> server's main thread and stall gameplay as well. Writing works
> similarily, you need to chop up outgoing data and maintain a write
> cursor for each "packet", so that you can try to make progress with a
> write and update the cursor as soon as there is work to be done.
> 
> I'd definitely go for a multiplexing TCP solution (similar to RCON)
> because of the problems with UDP. If something breaks with TCP, at
> least you know about it. Also, ordering can be very important in an
> admin scenario (what if the ban request comes in after the kick
> request, for instance).

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
programming. However, there are serious advantages to using TCP: In
addition to those that you mention, I am writing the manager in Twisted,
which has very nice handling of TCP traffic via connection factories
that generate a connection object for each connection to handle the
traffic. This would allow for a persistent connection between each
gameserver and the manager from the time the server is started and
announces itself to the manager, until it quits. Using TCP would also
allow safe transmission of data over non-local connections, if I would
have the need for that later on, e.g. by making a centralised manager.
The reason I haven't really considered using TCP

I currently have most of the protocol functionality for UDP set up both
for the manager and for BF2, but I will take a serious look at replacing
it with a TCP connection instead based on these advantages. You have
already done most of the grunt work on the RCON module anyway :)

> What about cPickle? All is not lost though, it's trivial to write a
> message packer in Python, even though it sucks to reinvent the wheel.

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.

Thanks,
Einar