Problem with continuous upload when nobody connected

DaveCore

Chieftain
Joined
Mar 5, 2008
Messages
4
Hi guys. My first post on this board. I am hosting 2 Pitboss games on different ports and the games work fine. I received a bill from my ISP for busting my upload limit for the month. I uploaded 90 gigabytes in the past 10 days, and I realized my Pitboss server was uploading at 85 KB/s which is my ISP limit. When I noticed that, I shut down one of my two Pitboss and dropped to 35 KB/s. I then shutdown the other and dropped to 0 KB/s. I started both games again and was still at 0 KB/s. It's been fine since yesterday now.

Has anyone else seen this before? I had no players connected when I noticed that upload issue. Anyone has any pointers?

Next time it happens, I'll sniff the packets to see where the data goes, for now I don't have anything more to work with.
 
If people exit to desktop this could happen i guess... Their connection is left hanging as it isn't closed before the game is and it will just continue upload...
 
If people exit to desktop this could happen i guess... Their connection is left hanging as it isn't closed before the game is and it will just continue upload...

Is this common knowledge in the Pitboss community? Can it really do that? This would be a huge design flaw but at this point in my limited Pitboss experience, nothing surprises me anymore about the way Pitboss works. Just it being peer to peer is strange enough...

Has anyone experiences this?
 
It is the same in any multiplayer game, exiting to desktop will leave the connection hanging and then sometimes you will not even be able to rejoin, until router resets.

Yes it is a design flaw, but it is very well known that this game is made for single player, they don't care much about multiplayer.
 
Oh dear. :(
I had a similar experience but I didn't doubt "Back to Desktop".
Is it prooved that "Back to Desktop" causes this problem?

My case: Three player Pitboss on WinXP, started end of March 2008, behind a router (lets call it "a"). The server window is not responding since some days after starting the game. (So I can't click "Save game" etc...) Restarting the server is possible, but it's immediately in "not responding mode". Playing itself is possible just normal.
Some days ago, we (all players) met and joined the game via internet. All were connected via Wifi by the same router (let's call it "b") to the internet. But this router b is not very stable, so we all lost several times our wifi connection and thereby the connection to the pitboss game.
After one or perhaps several more disconnects (I didn't count at that moment) we were not able to get connected again.

After getting home a day later (to router a and the pitboss server) I checked everything. Result: The pitboss server tried sending gigabytes of data. It tried to use more bandwidth than my "broadband" connection has upload (128kbit). Internet access was not possible behind router a (http, pop3, ssh, IM all didn't work). Resetting Router a had no effect. Killing the not responding pitboss server process did its job and all was okay by instant.

For me it's clear that "Back to Desktop" is not the only cause for the continous upload problem.
I'll play around with "Back to Desktop" and other connection losses the next days. I want to check out what conditions must be met to get the continous upload problem. For me it's not clear if it can happen always, or if more then one client has to be connected to the server.

Redarg
P.S.: This great game deserves a good multiplayer part!
 
I agree that this game needs better multiplayer implementation in all respects...

If you manage to find what causes the upload please post it as I am hosting 3 games at the momment and would be very interested to know...
 
I think I may have a lead on this issue. The problem happened to me again last week. Two of us were in the game and a third player was joining the game. We had a message that said "Player x is joining the game. Please wait." I then exited to desktop while this message was on the screen. And exactly at that time my server started to upload at the max bandwidth of my internet connection.

I have a feeling a player exiting the game while another player is joining will sometimes/all the time cause this issue.

To be continued...
 
I think I may have a lead on this issue. The problem happened to me again last week. Two of us were in the game and a third player was joining the game. We had a message that said "Player x is joining the game. Please wait." I then exited to desktop while this message was on the screen. And exactly at that time my server started to upload at the max bandwidth of my internet connection.

I have a feeling a player exiting the game while another player is joining will sometimes/all the time cause this issue.

To be continued...

Don't exit to desktop. Always exit to main menu.
 
Perhaps you remember my setup: Pitboss with wine running on a Debian Linux box using UDP-Port 51056. No one was connected to the server. My Civilization was waiting for other Civilizations to do there turn. I did the following for every disconnecting method:
  1. Connect to the running pitboss game from the internet
  2. Choose a civilization
  3. Log in
  4. "Disconnect"
    • "Back to Main Menu"
    • "Back to Desktop"
    • Unplugging the network cable/disabling wifi connection

During the test i ran "tcpdump"
Code:
tcpdump -XX port 2056 or port 51056
on the linux box to check what was happening.

Results:
  • Back to main Menu: UDP traffic stops immediately.
  • Back to Desktop: No UDP traffic instantly.
  • Connection breakdown: UDP traffic keeps being generated by the pitboss.
I did everything twice to be sure that it works or not.

So I could disconnect using "Back to Desktop" being alone on the pitboss without causing problems.
A wifi breakdown or disconnection of the internet access at the client side causes UDP traffic: Just some amount. After the first simulation of a connection crash at the client side internet access was still working at the 128kbit up/768kbit down broadband connection at the server.
After the second simulation without restarting the pitboss at first internet at the server side was ok, but a third login attemp could not be achived. And after this third login attemp all bandwidth was jammed by the UDP traffic of the pitboss and nothing worked. After closing the pitboss and waiting some time, which needed the router to calm down, things were fine again.


Someone wanted to sniff some packets:
This is a partial output of what pitboss jams my connection with:

Code:
linuxboxwithpitboss:~#tcpdump -XX port 2056 or port 51056
22:38:14.632727 IP linuxboxwithpitboss.51056 > some.host.with.dialin.net.2056: UDP, length 25
        0x0000:  0014 bfc9 1d97 000d 88b4 bb4c 0800 4500  ...........L..E.
        0x0010:  0035 0000 4000 4011 9a35 c0a8 160a d957  .5..@.@..5.....W
        0x0020:  f078 c770 0808 0021 7dab fefe 0001 1e00  .x.p...!}.......
        0x0030:  2ffd ffff ff01 ffff ffff b905 0000 0c00  /...............
        0x0040:  0000 01                                  ...
22:38:14.660724 IP linuxboxwithpitboss.51056 > some.host.with.dialin.net.2056: UDP, length 25
        0x0000:  0014 bfc9 1d97 000d 88b4 bb4c 0800 4500  ...........L..E.
        0x0010:  0035 0000 4000 4011 9a35 c0a8 160a d957  .5..@.@..5.....W
        0x0020:  f078 c770 0808 0021 7bab fefe 0001 1f00  .x.p...!{.......
        0x0030:  2ffd ffff ff01 ffff ffff b905 0000 0d00  /...............
        0x0040:  0000 01                                  ...
22:38:14.688702 IP linuxboxwithpitboss.51056 > some.host.with.dialin.net.2056: UDP, length 25
        0x0000:  0014 bfc9 1d97 000d 88b4 bb4c 0800 4500  ...........L..E.
        0x0010:  0035 0000 4000 4011 9a35 c0a8 160a d957  .5..@.@..5.....W
        0x0020:  f078 c770 0808 0021 79ab fefe 0001 2000  .x.p...!y.......
        0x0030:  2ffd ffff ff01 ffff ffff b905 0000 0e00  /...............
        0x0040:  0000 01                                  ...
22:38:14.689141 IP linuxboxwithpitboss.51056 > some.host.with.dialin.net.2056: UDP, length 25
        0x0000:  0014 bfc9 1d97 000d 88b4 bb4c 0800 4500  ...........L..E.
        0x0010:  0035 0000 4000 4011 9a35 c0a8 160a d957  .5..@.@..5.....W
        0x0020:  f078 c770 0808 0021 77ab fefe 0001 2100  .x.p...!w.....!.
        0x0030:  2ffd ffff ff01 ffff ffff b905 0000 0f00  /...............
        0x0040:  0000 01                                  ...
22:38:14.725566 IP linuxboxwithpitboss.51056 > some.host.with.dialin.net.2056: UDP, length 25
        0x0000:  0014 bfc9 1d97 000d 88b4 bb4c 0800 4500  ...........L..E.
        0x0010:  0035 0000 4000 4011 9a35 c0a8 160a d957  .5..@.@..5.....W
        0x0020:  f078 c770 0808 0021 75ab fefe 0001 2200  .x.p...!u.....".
        0x0030:  2ffd ffff ff01 ffff ffff b905 0000 1000  /...............
        0x0040:  0000 01                                  ...
22:38:14.759370 IP linuxboxwithpitboss.51056 > some.host.with.dialin.net.2056: UDP, length 25
        0x0000:  0014 bfc9 1d97 000d 88b4 bb4c 0800 4500  ...........L..E.
        0x0010:  0035 0000 4000 4011 9a35 c0a8 160a d957  .5..@.@..5.....W
        0x0020:  f078 c770 0808 0021 73ab fefe 0001 2300  .x.p...!s.....#.
        0x0030:  2ffd ffff ff01 ffff ffff b905 0000 1100  /...............
        0x0040:  0000 01                                  ...
22:38:14.759805 IP linuxboxwithpitboss.51056 > some.host.with.dialin.net.2056: UDP, length 25
        0x0000:  0014 bfc9 1d97 000d 88b4 bb4c 0800 4500  ...........L..E.
        0x0010:  0035 0000 4000 4011 9a35 c0a8 160a d957  .5..@.@..5.....W
        0x0020:  f078 c770 0808 0021 71ab fefe 0001 2400  .x.p...!q.....$.
        0x0030:  2ffd ffff ff01 ffff ffff b905 0000 1200  /...............
        0x0040:  0000 01                                  ...
22:38:14.760170 IP linuxboxwithpitboss.51056 > some.host.with.dialin.net.2056: UDP, length 25
        0x0000:  0014 bfc9 1d97 000d 88b4 bb4c 0800 4500  ...........L..E.
        0x0010:  0035 0000 4000 4011 9a35 c0a8 160a d957  .5..@.@..5.....W
        0x0020:  f078 c770 0808 0021 6fab fefe 0001 2500  .x.p...!o.....%.
        0x0030:  2ffd ffff ff01 ffff ffff b905 0000 1300  /...............
        0x0040:  0000 01                                  ...
22:38:14.760572 IP linuxboxwithpitboss.51056 > some.host.with.dialin.net.2056: UDP, length 10
        0x0000:  0014 bfc9 1d97 000d 88b4 bb4c 0800 4500  ...........L..E.
        0x0010:  0026 0000 4000 4011 9a44 c0a8 160a d957  .&..@.@..D.....W
        0x0020:  f078 c770 0808 0012 5ef0 fefe 0001 2600  .x.p....^.....&.
        0x0030:  2fdc dc01                                /...
22:38:14.760944 IP linuxboxwithpitboss.51056 > some.host.with.dialin.net.2056: UDP, length 25
        0x0000:  0014 bfc9 1d97 000d 88b4 bb4c 0800 4500  ...........L..E.
        0x0010:  0035 0000 4000 4011 9a35 c0a8 160a d957  .5..@.@..5.....W
        0x0020:  f078 c770 0808 0021 6cab fefe 0001 2700  .x.p...!l.....'.
        0x0030:  2ffd ffff ff01 ffff ffff b905 0000 1400  /...............
        0x0040:  0000 01                                  ...
10 packets captured
10 packets received by filter
0 packets dropped by kernel

So. What now?
Looks like there is no timeout for this traffic, or the timeout is much too large.
Can someone proof this on a windows server?(Perhaps it's a bug with wine...) And a test with mutliple connected players would be interesting.

So long
Redarg
 
Redarg: you are connecting to the game from a LAN right? So exiting to desktop would not affect it I would imagine.

About the connection issues you are propably right, I don't know if Hamatchi or civstats uploader have something to do with the problem.
 
Hello Redarg, I'd be more than glad to help you pin that down!
I'm in the european timezone and can easily make a connection crash (I do wonders there...) If it helps pinpointing the problem.
Though I don't know if we can expect any corrections.

Myself I'm counting more on a fan-made watchdog to control the good execution of the pitboss server and relaunch it if needed.
 
Redarg: you are connecting to the game from a LAN right? So exiting to desktop would not affect it I would imagine.
Yes. Following setup:
Pitboss <-> LAN<-> Router a <-> Internet <-> Router b <->LAN <-> Client
Why should "Exit to Desktop" terminate the connection by another method when the setup is:
Pitboss <-> LAN<-> Router a <-> Internet <-> Client
Or
Pitboss <-> LAN<-> Client (Will be checked by me)?
For me that doesn't make sense. Different methods for terminating a connection would be a waste of program code. And more code means greater chance for bugs...

About the connection issues you are propably right, I don't know if Hamatchi or civstats uploader have something to do with the problem.
I don't know too. I neither use Hamachi nor the Civstats uploader.

A patch would be very nice to remove this bug.
But, for me, it would help if I can tell all players at which point they have to take care.

Redarg
 
Yesterday i measured the upload on my Linux box:
From ntop:
Code:
IP Address:	88.xx.x5x.xxx
First/Last Seen:	Fri Jun 13 23:12:21 2008  -  Fri Jun 13 23:17:17 2008 [Inactive since 0 sec]
Domain:	dsl.tropolys.de
Host Location:	Remote (outside specified/local subnet)
IP TTL (Time to Live):	121:121 [~7 hop(s)]
Total Data Sent:	12.9 KBytes/208 Pkts/0 Retran. Pkts [0%]
Total Data Rcvd:	31.3 MBytes45,600 Pkts/0 Retran. Pkts [0%]

189 Active TCP/UDP Sessions

Client	mue-88-*.dsl.tropolys.de   :2056
Server	pitboss.dyndns.org   :8056
Data Sent	7.7 KBytes
Data Rcvd	30.7 MBytes
Active Since	Fri Jun 13 23:12:21 2008
Last Seen	Fri Jun 13 23:17:17 2008
Duration	04:56:00
Inactive	0 sec
Data Rcvd means that the Client has received this data.
So in 5 minutes about 30 Mb were tried to be transferred. That's 100 kbyte/s. As my dialup can do about 14 kbyte/s: Bad for my internet accessibility.
Calculating around: = 360 Mb/h = 8,6 Gb/d = 60,5 Gb/w

Keep in mind that this is just ONE SINGLE measurement. So there is no statisticel relevance.

By the way:
In a german Civ forum someone uses
"Netlimiter"
on Windows to avoid the upload problem. (But it costs 25 &#8364;...)
I'd like to have a solution for Linux. (And one for Winows that's free of costs.) Does anyone has one?

Redarg
 
Top Bottom