From: Thomas Themel <thomas.themel@cp...> - 2004-03-01 23:46:10
[I've got exactly the same problem, posted to -users in January but
didn't get to resolve this.]
> "forward blocked" means that the T120 socket is not available anymore on
> Client2 side or the transmission operation failed for reasons like "socket
> busy"( you should send the lines of log around "forward blocked" ).
I have already posted the exact information to openh323gk-users back in
> So the TCP connection initializes well as you received some packets of Client1.
> That means you don't see the following message on your logs:
> "T120 xxx.xxx.xxx.xxx:pppp DIDN'T ACCEPT THE CALL"
Nope, never seen it. The call _IS_ accepted by the low-bandwidth client,
sharing applications that don't hog bandwidth (like Notepad) is not a
> The best way to see where the pb comes from is to use a tool like ethereal to
> see if packets continue to arrive on Client2 from gk.
Nope. I've done a few tcpdumps, and what I found were extremely asymmetric
TCP window sizes - the GK stuffs the transmit window and then fails, since Linux
wants to block further sends.
> -If YES you must increase your TCP receiving buffer on client2 (at least on the
> system and also if you can on your client application)
Shouldn't be a problem since it works fine once the client has enough
> -If NO you must increase the TCP sending buffer of your GK.
I'd need a little help to the code there... I've looked through
ProxyThread, and it seems that its basic mode of operation is to fetch
data as soon as it comes in and forward it. This conflicts with TCP's
bandwidth management mechanism, which blocks writing to the socket once
send window is filled. Improving buffering on the GK won't help the
actual problem here - when data is received faster than it can be
forwarded, you need to throttle the recv() speed on the receiving side
of the proxy to tell the fast client->proxy connection "Whoah, slow down
a bit, can't handle this much traffic.".
My understanding of the actual problem causing the connection drops here
is that the ProxyThread drops the chunk it wanted to send once it gets
into the 'forward blocked' case. Upon later resumption this leads to
protocol violations, and thus the clients terminate the connection.
What I think it should do is select() on the send socket and wait for it
to become writable again.
All of this is to be taken with a grain of salt since it's just
theorizing from what I saw on traces and tcpdumps.
Please give me an indication if someone who knows about the code would
be willing to help with this, I am planning a production deployment that
depends on T.120 working around here and would greatly prefer to run
unmodified GK versions for it.
Thomas Themel | CenterPoint Connective Software Engineering GmbH
Hauptplatz 8/4 | System Administrator / Software Developer
A-9500 Villach | <http://www.cpointc.com/>
+43 676 846623-13| work thomas.themel@... play thomas@...