[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: xAP EOM identifier in xAP v1.3
--001485e8cb1fd3c59b04739de986
Content-Type: text/plain; charset=ISO-8859-1
2009/9/15 Kevin Hawkins <yahoogroupskh@xxxxxxx>
> This is a graphical front end iPhone application (iViewer byCommand
> Fusion) . They have TCP/UDP socket support to handle two way
> interaction with remote devices for status updates and control. They
> are not writing anything specifically for xAP - just hoping to be able
> to support it, and their parsing works best if they can handle
complete
> messages by way of an EOM identifier or UDP receive event.
>
> In practice they have experienced occasional truncated or concatenated
> messages and so were suggesting an EOM would be most helpful. The
> truncation may well be due to a partial concatenation which would
> otherwise exceed the a buffer boundary and not any data lost. They
want
> something compatible with as much xAPware as possible and as they're
> not coding specifically for xAP and are using UDP. The double '0A'
> seems most suitable for them and anyone else with a similar need.
>
> The UDP datagram size seems to be quite a debateable issue. RFC 879
> apparently says "The default IP Maximum Datagram /size/ is
576" but it
> seems this is now rather archaic in terms of implementations and
rarely
> a LAN concern. I did find that AMX truncates at 512 bytes though,
> whilst trying to get my xAP AMX module running - in the end I had to
use
> TCP to xServer.. I think this was more a convenient software buffer
> size than any other reason and I hope they have increased this in
later
> firmware
>
So the AMX isn't RFC compliant :-)
The RFC you've quoted from is defining the lowest common denominator to
guarantee interoperability - the absolute maximum size of a UDP datagram
overall is defined by the bounds of the 16 bit length field in the UDP
header (as per Edward's experiments)
I can see that your terminator approach may be useful to address the issues
that Command Fusion are seeing, but I know first hand that OSX does do the
right thing with UDP datagram delivery (and if it routinely behaved in the
way described above it would break dhcp, dns and ....). I wonder whether
the
code originating the xAP messages may be defective?
Patrick
--001485e8cb1fd3c59b04739de986
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<head>
<style type=3D"text/css">
<!--
/* start of attachment style */
.ygrp-photo-title{
clear: both;
font-size: smaller;
height: 15px;
overflow: hidden;
text-align: center;
width: 75px;
}
div.ygrp-photo{
background-position: center;
background-repeat: no-repeat;
background-color: white;
border: 1px solid black;
height: 62px;
width: 62px;
}
div.photo-title=20
a,
div.photo-title a:active,
div.photo-title a:hover,
div.photo-title a:visited {
text-decoration: none;=20
}
div.attach-table div.attach-row {
clear: both;
}
div.attach-table div.attach-row div {
float: left;
/* margin: 2px;*/
}
p {
clear: both;
padding: 15px 0 3px 0;
overflow: hidden;
}
div.ygrp-file {
width: 30px;
valign: middle;
}
div.attach-table div.attach-row div div a {
text-decoration: none;
}
div.attach-table div.attach-row div div span {
font-weight: normal;
}
div.ygrp-file-title {
font-weight: bold;
}
/* end of attachment style */
-->
</style>
</head>
<html><head>
<style type=3D"text/css">
<!--
#ygrp-mkp{
border: 1px solid #d8d8d8;
font-family: Arial;
margin: 14px 0px;
padding: 0px 14px;
}
#ygrp-mkp hr{
border: 1px solid #d8d8d8;
}
#ygrp-mkp #hd{
color: #628c2a;
font-size: 85%;
font-weight: bold;
line-height: 122%;
margin: 10px 0px;
}
#ygrp-mkp #ads{
margin-bottom: 10px;
}
#ygrp-mkp .ad{
padding: 0 0;
}
#ygrp-mkp .ad a{
color: #0000ff;
text-decoration: none;
}
-->
</style>
</head>
<body>
<!-- **begin egp html banner** -->
<br><br>
<!-- **end egp html banner** -->
<br><br><div class=3D"gmail_quote">2009/9/15
Kevin Hawkins <span dir=3D"ltr=
"><<a href=3D"mailto:yahoogroupskh@xxxxxxx";>yahoogroupskh@googlem=
ail.com</a>></span><br><blockquote
class=3D"gmail_quote" style=3D"border=
-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex;
padding-lef=
t: 1ex;">
This is a graphical front end =A0iPhone application (iViewer
byCommand<br>
Fusion) . =A0They have TCP/UDP socket support to handle two way<br>
interaction with remote devices for status updates and control. =A0
They<br=
>
are not writing anything specifically for xAP - just hoping to be
able<br>
to support it, and their parsing works best if they can handle
complete<br>
messages by way of an EOM identifier or UDP receive event.<br>
<br>
In practice they have experienced occasional truncated or
concatenated<br>
messages and so were suggesting an EOM would be most helpful.
=A0The<br>
truncation may well be due to a partial concatenation which would<br>
otherwise exceed the a buffer boundary and not any data lost. =A0They
want<=
br>
something compatible =A0with as much xAPware as possible and as
they're=
<br>
not coding specifically for xAP and are using UDP. =A0The double
'0A=
9;<br>
seems most suitable for them and anyone else with a similar need.<br>
<br>
The UDP datagram size seems to be quite a debateable issue. =A0RFC
879<br>
apparently says "The default IP Maximum Datagram /size/ is
576" b=
ut =A0it<br>
seems this is now rather archaic in terms of implementations and
rarely<br>
a LAN concern. =A0I did find that AMX truncates at 512 =A0bytes
though,<br>
whilst trying to get my xAP AMX module running - in the end I had to
use<br=
>
TCP to xServer.. =A0I think this was more a convenient software
buffer<br>
size than any other reason and I hope they have increased this in
later<br>
firmware<br>
<font
color=3D"#888888"></font></blockquote><div><br>So
the AMX isn't R=
FC compliant :-)<br>The RFC you've quoted from is defining
the lowest c=
ommon denominator to guarantee interoperability - the absolute maximum
size=
of a UDP datagram overall is defined by the bounds of the 16 bit length fi=
eld in the UDP header (as per Edward's experiments)<br>
<br>I can see that your terminator approach may be useful to address
the is=
sues that Command Fusion are seeing, but I know first hand that OSX does
do=
the right thing with UDP datagram delivery (and if it routinely behaved in=
the way described above it would break dhcp, dns and ....). I wonder wheth=
er the code originating the xAP messages may be defective?<br>
<br>Patrick<br></div></div>
<!-- **begin egp html banner** -->
<br>
=20=20=20=20
=20=20=20=20
<br>
<!-- **end egp html banner** -->
<div width=3D"1" style=3D"color: white; clear:
both;"/>__._,_.___</div>
<!-- Start Recommendations -->
<!-- End Recommendations -->
<!-- **begin egp html banner** -->
<img src=3D"http://geo.yahoo.com/serv?s=3D97476590/grpId=3D9629476/grpspI=
d=3D1705007709/msgId=3D1997/stime=3D1253022054" width=3D"1"
height=3D"1"> <=
br>
<!-- **end egp html banner** -->
=20=20
<!-- **begin egp html banner** -->
<br>
<div style=3D"font-family: verdana; font-size: 77%; border-top: 1px
s=
olid #666; padding: 5px 0;" >
Your email settings: Individual EmailTraditional <br>
<a href=3D"http://groups.yahoo.com/group/xAP_developer/join;_ylc=3DX3=
oDMTJmN2ZsNGI2BF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5B=
HNlYwNmdHIEc2xrA3N0bmdzBHN0aW1lAzEyNTMwMjIwNTQ-">Change settings
via the We=
b</a> (Yahoo! ID required) <br>
Change settings via email: <a href=3D"mailto:xAP_developer-digest@yah=
oogroups.com?subject=3DEmail Delivery: Digest">Switch delivery to
Daily Dig=
est</a> <a href =3D "mailto:xAP_developer-fullfeatured@xxxxxxx?su=
bject=3DChange Delivery Format: Fully Featured">Switch to Fully
Featured</a=
> <br>
<a href=3D"http://groups.yahoo.com/group/xAP_developer;_ylc=3DX3=
oDMTJkaTBycnE4BF9TAzk3NDc2NTkwBGdycElkAzk2Mjk0NzYEZ3Jwc3BJZAMxNzA1MDA3NzA5B=
HNlYwNmdHIEc2xrA2hwZgRzdGltZQMxMjUzMDIyMDU0">
Visit Your Group=20
</a>
<a href=3D"http://docs.yahoo.com/info/terms/";>
Yahoo! Groups Terms of Use
</a>
<a href=3D"mailto:xAP_developer-unsubscribe@xxxxxxx?subject=
=3DUnsubscribe">
Unsubscribe=20
</a>=20
<br>
</div>
<br>
<!-- **end egp html banner** -->
<div style=3D"color: white; clear:
both;"/>__,_._,___</div>
</body>
</html>
--001485e8cb1fd3c59b04739de986--
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|