[Date Prev][Date Next][Thread Prev][Thread Next] - [Date Index][Thread Index][Author Index]
Re: internet feeds
- Subject: Re: [amsat-bb] internet feeds
- From: Steve Dimse <sdimse@xxxxxxxxxxxxx>
- Date: Tue, 2 Jan 2001 13:23:51 -0500
On 12/30/00 9:00 AM Ron Parise (ron.parise@gsfc.nasa.gov) wrote:
>There are actually two applications involved in my project. The first one
>is the dataserver itself. The second is a bit of "glueware". P3T and its
>compatible apps act as servers, i.e. they expect someone to connect to
>them on a TCP socket. My dataserver expects to receive UDP packets. I have
>written a simple application that needs to be run on any computer that
>intends to be a data source. After you run P3T (or IZ8BLY's demod for
>example)
>you then run my app. It connects to P3T as a client, receives the TLM
>frames on the TCP socket, and sends them to the Goddard server as UDP
>packets.
>
Why do you use UDP for input? Is there some higher level ack protocol, or
does the glueware simply blast the packets out on the 'net and hope they
get through?
Four years ago, when I was designing APRS internet feed, a rather
similar system, I chose TCP on both ends. This guarantees that each
packet gets from the remote receiver to the central server, and then out
to the client programs. When the receiver and central server run on a
local ethernet network, the chance of packet loss is minimal, and it
sounds like this situation may have been what your software was
originally designed for. However, over the internet, the risk of packet
loss is higher, I commonly see 5% loss on connection during times of peak
internet traffic.
The programming for TCP and UDP is very similar, and IMHO well worth the
small extra effort.
Steve K4HG
----
Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org
AMSAT Home