[Date Prev][Date Next][Thread Prev][Thread Next] - [Date Index][Thread Index][Author Index]

Re: internet feeds

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 
 >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 
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