Lost UDP?

[;i]

I am writing a battle.net proxy program that sits between battle.net and the game client, relaying messages from each.  The problem that I am having is that when logged on through the proxy, I can no longer join games.  The packet is sent requesting the game list, the server replies, and then nothing happens.  Any attempt to join a game results in a "Latency too high" error.  When logging without the proxy, UDP pings are sent to each game in the list.  These pings don't seem to be sent off with the proxy in place.  If anyone has suggestions, I'm open.

[Mephisto]

I think that error results when Battle.net determines that the time it takes to send packets between the game host and the client is too long.  This is probably because you're using a proxy which are known to be extremely slow/laggy.

[;i]

Somehow, I don't think so.  The proxy software is local so any time spent communicating with it would be next to 0.

[;i]

It looks like this:

Starcraft <-> Proxy <-> Battle.net

All the proxy does is forward data, no proxying protocol involved.

[tA-Kane]

Be sure that your proxy is relaying data for not only TCP, but UDP as well, especially if the proxy is on a different public IP address. If the server thinks your client IP is one thing (your proxy's address), but it's really another (your local IP), then it may report that IP address to clients whom wish to join your game.

Additionally, if your proxy is running on the same machine and has the UDP socket bound to the same port as the client binds its UDP socket to (a very annoying thing, in my opinion, but I've heard it's possible under some operating systems), that could be the cause.

Have you tried setting up a game server on a different machine, and then packetlogging data on both machines for both connection setups (client connecting with and without proxy)? That may be useful if both of my other ideas are unhelpful.

[;i]

I am relaying data for UDP as well, as I receive the initial UDP pings during the logon process.  I have not yet tried creating a game, but for the moment, it is joining that I would like to get working.  I do bind my UDP socket to 6112, so I guess that could be the problem, but I don't see any alternative if I want to be able to receive the UDP data during logon.  No, I've not tried setting up a server on a different machine and logging both...  Mainly because I don't have a server.

Edit: Last night, I tried using a proxy UserLoser made and tested on his computer.  He said that he was able to join games with it, but when I attempted to use it, logging on told me that I didn't support UDP.  So I don't know if that's indicative of a problem with my connection or problems with the software.

[iago]

The problem is that when you join a game, the other players are given your "address", which happens to be the address of the proxy.  They all send their UDP packets to the proxy, and the proxy has no idea what to do with them (how is it supposed to know the UDP packets are destined for you?). 

[;i]

The address of the proxy is my address.

Edit: And I hadn't tested this before, but this morning, I was able to create a game and people were able to join it just fine...  So I don't know what's going on with my being able to join games.

[Adron]

Both you and Starcraft want to bind to the same port. If you're on an OS where it succeeds, perhaps who actually gets the packets will be different from time to time.

You need to modify packet contents to translate IP addresses to connect to as well as ports of clients if you want the packets to pass through your proxy. This you have to do both to parts of the tcp stream and to the udp data.

If you don't want the udp packets to pass through your proxy, and they're on the same IP, just don't bind any udp port in your proxy and everything should work just fine.

[;i]

You need to modify packet contents to translate IP addresses to connect to as well as ports of clients if you want the packets to pass through your proxy. This you have to do both to parts of the tcp stream and to the udp data.

Which TCP packets need modifying?  When I request game list and get host IP/port, shouldn't the game client respond to receiving that by sending UDP pings to each host?

If you don't want the udp packets to pass through your proxy, and they're on the same IP, just don't bind any udp port in your proxy and everything should work just fine.

I tried just doing the TCP and (as with using UserLoser's proxy), I was given the no UDP support error and greyed out Create/Join buttons in Starcraft.

[UserLoser.]

My proxy just forwarded TCP, I was able to join games and didn't get the no UDP icon when logging on.  Odd?

[;i]

Something else that's rather odd...  I ran the proxy on my system and connected to it using Brood War on another computer.  That one is able to join games even with the proxy in place.

[MyndFyre]

My proxy just forwarded TCP, I was able to join games and didn't get the no UDP icon when logging on.  Odd?

So then perhaps you can be sending data from a different apparent IP address than the TCP data is coming?

[Adron]

You need to modify packet contents to translate IP addresses to connect to as well as ports of clients if you want the packets to pass through your proxy. This you have to do both to parts of the tcp stream and to the udp data.

Which TCP packets need modifying?  When I request game list and get host IP/port, shouldn't the game client respond to receiving that by sending UDP pings to each host?

If you want the packets to pass through your proxy, you need to modify the host IP/port to point to your proxy..... Shouldn't that be obvious?

[;i]

If you want the packets to pass through your proxy, you need to modify the host IP/port to point to your proxy..... Shouldn't that be obvious?

Oh, you mean excepting the fact that it works completely for some people as is?  And that for others, they can create games fine, but not join them?  And others are told they have no UDP on connect?  All with the same build, I might add.  This sounds like a problem other than the "obvious" modification of host IP and port.