<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Lloyd Wood wrote:
<blockquote cite="mid7.0.1.0.0.20060425223053.05669c78@surrey.ac.uk"
type="cite">At Tuesday 2006-04-25 13:48 -0700, Scott Burleigh wrote:
<br>
<blockquote type="cite">Lloyd Wood wrote:<br>
<blockquote type="cite">" CFDP can run over TCP"
<br>
<br>
has anyone ever used CFDP over TCP?
<br>
</blockquote>
I believe a TCP "UT layer" adapter for CFDP has been built and tested
at JPL, but I'm pretty sure it's never been used in any operational
sense.
<br>
</blockquote>
so this wouldn't meet the "two interoperable independent
implementations needed to make a standard" requirement, then?<br>
</blockquote>
No, I don't think anybody has yet proposed making a TCP UT layer for
CFDP into a standard. It wouldn't be a particularly challenging
problem if someone did, I guess.<br>
<blockquote cite="mid7.0.1.0.0.20060425223053.05669c78@surrey.ac.uk"
type="cite">
<blockquote type="cite">Unacknowledged CFDP over TCP isn't quite as
outlandish a stack as it might seem: TCP assures the in-order data
arrival that the CFDP procedures rely on (which on rare occasions
produces some surprising behavior in acknowledged CFDP over UDP),
<br>
</blockquote>
surprising behaviour? not bugs/design flaws?</blockquote>
No, not bugs, and not really design "flaws", though I'd certainly agree
that this is a limitation of the design. A fairly well documented one,
in fact: Note 5 of section 3.4 of the specification says:<br>
<blockquote>
<p class="Noteslevel1" style="page-break-after: avoid;"><!--[if !supportLists]--><span
style=""><span
style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;"></span></span><!--[endif]-->The
assumed minimum underlying quality of service is:<o:p></o:p></p>
<p class="MsoList2" style="line-height: 12.5pt;"><!--[if !supportLists]--><span
style="">–<span
style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">
</span></span><!--[endif]-->with possible errors in the delivered
UT_SDUs;<o:p></o:p></p>
<p class="MsoList2" style="line-height: 12.5pt;"><!--[if !supportLists]--><span
style="">–<span
style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">
</span></span><!--[endif]-->incomplete, with some UT_SDUs missing;<o:p></o:p></p>
<span style="">–<span
style="font-family: "Times New Roman"; font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal;">
</span></span><span
style="font-size: 12pt; font-family: "Times New Roman";">in sequence;
i.e., the delivered UT_SDUs are
delivered in the order in which they were transmitted.<span style=""></span></span><br>
<span style="font-size: 12pt; font-family: "Times New Roman";"><span
style=""></span></span></blockquote>
<!--[endif]--><span
style="font-size: 12pt; font-family: "Times New Roman";"><span style="">CFDP
is designed to run over a deep-space radio link, where the laws of
physics pretty much assure that if bits arrive at all they arrive in
the order in which they were transmitted. You can run it in other
contexts, but if you do so it may be helpful to read the specification
and know what you're doing. Otherwise -- if, for example, you run over
UDP/IP in the Internet, where packets can take different paths and
therefore sometimes arrive out of transmission order -- the behavior of
a conformant and correctly operating implementation of CFDP may on rare
occasions surprise you.<br>
<br>
Scott<br>
</span></span>. <br>
</body>
</html>