TCP timeouts

hello. I have the following setup:

realtime video client <----- FHSS 802.11 -----< linux gw <--- wired --<
ethernet video encoder (sends UDP and is governed by a tcp control channel)

I run into problems when i have a very low signal strength on the wireless
link... errors start to occur and the wireless ARQ retransmission starts
thus creating significant video delay on the client. for the application,
i'd rather have no data then stale data.

the video encoder sends a TCP packet roughly every second which tells the
video client if everything is fine. It will sit there waiting for a
response. The software wiill time out eventually but unfortunatly the
timeout value isnt settable by me and is far too big.

I think what is happening is the queue on the gateway just grows and grows
while the wireless channel sorts itself out. unfortunatly the data becomes
stale and no longer of use to us. id rather just disgard the old data
instead of letting it pile up, causing even more work for the wireless
channel.

I think the solution might be to kill the TCP channel after x seconds of
inactivity. killing the tcp channel will cause the transmission of video to
cease instead of getting queued up in the gateway.

Your comments on my issue would be greatly appreciated.

Regards

Justin Todd
www.diversedev.com

Justin Todd wrote:

> hello. I have the following setup:
>
> realtime video client <----- FHSS 802.11 -----< linux gw <--- wired --<
> ethernet video encoder (sends UDP and is governed by a tcp control channel)
>
> I run into problems when i have a very low signal strength on the wireless
> link... errors start to occur and the wireless ARQ retransmission starts
> thus creating significant video delay on the client. for the application,
> i'd rather have no data then stale data.
>
> the video encoder sends a TCP packet roughly every second which tells the
> video client if everything is fine. It will sit there waiting for a
> response. The software wiill time out eventually but unfortunatly the
> timeout value isnt settable by me and is far too big.
>
> I think what is happening is the queue on the gateway just grows and grows
> while the wireless channel sorts itself out. unfortunatly the data becomes
> stale and no longer of use to us. id rather just disgard the old data
> instead of letting it pile up, causing even more work for the wireless
> channel.
>
> I think the solution might be to kill the TCP channel after x seconds of
> inactivity. killing the tcp channel will cause the transmission of video to
> cease instead of getting queued up in the gateway.
>
> Your comments on my issue would be greatly appreciated.

Poor programming... The use of a TCP control channel to control a UDP
transmission is poor programming. It should be using UDP with acks and resends
of lost packets.

--
Phil Frisbie, Jr.
Hawk Software
http://www.hawksoft.com