[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: xAP EOM identifier in xAP v1.3
--00c09fd1aeac46f5260473c2f47b
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cool!
I'm not sure the transport wrapper over TCP 'breaks everything' - I've used
it for TCP routing of xAP over the internet framed using the transport
wrapper for several years now (I even demoed it as a means of remotely
accessing my home intranet via xAP at the inaugural HA weekend meet many
moons ago), but perhaps I'm missing something from your requirements? All
the tcp hub has to do is strip off the start and end delimiter before
rebroadcast, and likewise frame any received udp messages with an
<stx>,
<etx> if operating bi-directionally. Admittedly it's an additional
(minimal=
)
cost that isn't present with the double-0A scheme, but the benefits of
bein=
g
able to detect the start of frame, and the benefits of being able to apply
this approach to any async transport, not just tcp/ip, outweigh that in my
mind. And it is in the spec already ;-)
Personally, I don't see a need for a delimiter at the end of a message in
UDP xAP. I'm sure I'm going to be outvoted, but look at all the other UDP
protocols out there - it's not common practice because it's not technically
necessary, and as such it's just adding unnecessary cruft to xAP!
Cheers
Patrick
2009/9/17 Edward Pearson <edward.mailgroup@xxxxxxx>
>
>
> You=92re right, to get a connection in good time that=92s not
statically
> configured it=92d need a request/offer message pair.
>
>
>
> The experimental hub I have here is designed to address one specific
> problem only =96 unreliability over WiFi.
>
> In runs as a master slave arrangement. In master mode it accepts
incoming
> tcp connections on port 3639. In slave mode (deployed on the WiFi
machine=
)
> it=92s configured (statically) with the IP address or hostname of the
mas=
ter
> hub to which it connects over tcp. The tcp connection is used one-way
onl=
y,
> from master to slave. The master forwards all xAP messages it receives
(o=
n
> udp) to all its local udp clients (as usual) and to any connected tcp
> clients. The slave forwards all messages received on its tcp
connection t=
o
> its local clients on udp. Works a treat. Now I can lie on the sofa
debugg=
ing
> Viewer v4 (it=92ll be out really, really soon now I promise) on my
WiFi l=
aptop
> without wondering where 15% of the messages have gone.
>
>
>
> I mention all this mainly (and at risk of getting back to Kevin=92s
origi=
nal
> point of this thread which I=92m feeling guilty of hijacking horribly)
be=
cause
> I needed to address the problem of the segregation of messages in a
stre=
am
> to get this to work. So I experimented with several schemes getting a
go=
od
> feel for the practical pro=92s and cons of each. Initially I went for
the
> STX/ETX method from the transport wrapper since it=92s what=92s in the
ex=
isting
> spec (but opting out of the CRC). Later I used the double LF
termination.
> The transport wrapper is somewhat easier to work with. For instance,
it=
=92s
> easier to re-sync to the a message start with transport wrapper; just
wai=
t
> for the next STX (a single byte), vs. needing match all of
> =93xap-[headerhbeat]<lf>=94. Message ends are similar: ETX (1
byte) vs <=
lf><lf>
> (2 bytes). But all this is irrelevant in the udp world. Introducing
STX/=
ETX
> here would break everything while double <lf> is nicely
backwards
> compatible.
>
>
>
> (and finally, my point relevant to the thread start)
>
>
>
> I don=92t think double <lf> is the right solution for Kevin=92s
developer=
s=92
> wireless app problem; it=92d help them out somewhat but I think it
more t=
han
> likely that it=92s =91papering over=92 a bug in or around their
network s=
tack. But
> there is a valid need lurking in here; without message-level
delimiting i=
n
> the original spec, implementers of xAP commonly run up against the
proble=
m
> of knowing where the end of a message is while parsing messages. The
doub=
le
> <lf> definitely helps here. So given that it=92s easy to add,
helps in so=
me
> folks, eases adoption and causes no backwards compatibility issues,
I=92m
> happy that it should go into the v1.3 spec.
>
>
>
> *From:* xAP_developer@xxxxxxx [mailto:
> xAP_developer@xxxxxxx] *On Behalf Of *Patrick Lidstone
> *Sent:* 16 September 2009 12:00
>
> *To:* xAP_developer@xxxxxxx
> *Subject:* Re: [xAP_developer] xAP EOM identifier in xAP v1.3
>
>
>
>
>
> I agree that checksums are not appropriate to TCP connections, the
> transport wrapper already designates them as optional.
>
> I don't think hubs currently send heartbeats? If they do, it's not
explic=
it
> in the spec. (Mine doesn't). We also need a mechanism to differentiate
> between multiple hubs (since most people will generally run at least
one =
hub
> per vm).
>
> Is a TCP hub going to relay all traffic to all TCP endpoints? That
won't
> scale very well... but it's also not clear how the filtering etc. will
wo=
rk.
> Administering filters manually works fine for the odd serial segment,
but
> it's not going to be viable for a large number of endpoints.
>
> Heartbeats are broadcast every minute or so typically, so that's going
to
> result in start up times of up to two minutes for a tcp end point. Is
tha=
t
> acceptable? If not, do we reduce the new tcp hub heartbeat interval?
Or i=
s
> there a mechanism for an endpoint to poke a hub and elicit a
heartbeat?
>
> And lastly, is there merit in some kind of referrer system to allow
for
> load-balancing and automated failover of tcp connections across more
than
> one hub? If so, how would this work?
>
> Patrick
>
> 2009/9/15 Edward Pearson <edward.mailgroup@xxxxxxx>
>
>
>
> I don=92t mean that packet fragmentation or re-ordering are myths =96
jus=
t that
> when dealing with xAP at the IP stack (socket) interface you are
dealing
> with datagrams not data packets so you don=92t need to worry about
those
> packet aspects. There was a design decision to limit xAP datagrams to
150=
0
> bytes to improve the likely coverage of correctly sent datagrams in a
wor=
ld
> of IP stacks of varying quality. It=92s no more important than that.
Read=
ers
> of the spec seem to attach more importance to it than it needs
(there=92s=
the
> myth aspect). To program xAP you don=92t need to worry about
fragmentati=
on
> and reordering =96 just keep your datagrams 1500 bytes or less and let
th=
e
> stack do its thing.
>
>
>
> Sometimes an app goes a bit wild (xAP news has occasionally been a
useful
> test source) and big xAP messages are generated =96 and they get
delivere=
d
> too! It=92s normally the input buffer of the receiving app (eg hub)
that
> breaks first.
>
>
>
> On the tcp framing, I=92d suggest that implementing the CRC part
(irrelev=
ant
> on a reliable stream) is a waste of most people=92s time; by far more
use=
will
> be made of tcp than any kind of serial/485/etc networks so they=92d be
sh=
aring
> development of an implementation with nobody.
>
>
>
> Discovery can be done simply with the existing hub heartbeat message.
Jus=
t
> need to agree on an extra block that advertises the port number of the
tc=
p
> service =96 which I assume, by default would be 3639.
>
>
>
> Having read the 802.11 spec, I now understand why broadcast udp from
an A=
P
> to a NIC is so un-reliable. And ad-hoc mode is a real disaster!
>
>
>
> *From:* xAP_developer@xxxxxxx [mailto:
> xAP_developer@xxxxxxx] *On Behalf Of *Patrick Lidstone
> *Sent:* 15 September 2009 14:15
>
>
> *To:* xAP_developer@xxxxxxx
> *Subject:* Re: [xAP_developer] xAP EOM identifier in xAP v1.3
>
>
>
>
>
> Hi Edward,
> Please see in-line responses...
>
> 2009/9/15 Edward Pearson <edward.mailgroup@xxxxxxx>
>
>
>
> The double 0x0a terminator works for me, it=92s simple to implement
=96 a=
lready
> done for my stuff.
>
>
>
> ...but it isn't robust unless the message is sent as a single
datagram, a=
nd
> if it is sent as a single datagram, the os should deliver it as such
-- a=
nd
> if it doesn't, adding an eom marker isn't going to help.
>
> For reliable streams, such as TCP, I generally frame the messages
with
> STX and ETX.
>
>
>
> I thought all this business about 1500 bytes was somewhat urban myth
(at
> least as it applies to xAP). The data packet size is not what=92s
importa=
nt;
> it=92s how the particular IP stack implementation deals with
>datagrams<
> that=92s the key.
>
>
> I don't understand what you are syaing here? The data packet size is
> inextricably linked to the IP stack. What aspect is it that you
consider =
to
> be an urban myth?
>
>
> I only have experience of the two most recent Windows stacks (XP and
> Vista) which I agree are likely more capable than old embedded stacks.
My
> experiments with Wireshark show that those stacks will happily deal
with
> fragmentation and defragmentation. 64KB in a single datagram? No
problem =
if
> your receive buffer is long enough (even if you force a small MTU).
>
> Yes, agreed, OSes perform fragmentation for you. The individual
fragment=
s
> have a maximum size as determined by the MTU. For pragmatic, practical
> reasons, xAP needs to define a maximum overall message size, and for
> convenience's sake that was set as equal to the 'standard' MTU size.
Devi=
ces
> which use a smaller MTU *should *fragment and reassemble seamlessly
> provided that the correct socket options have been set to define the
maxi=
mum
> UDP packet size. By electing to use a single MTU's worth of data, we
we
> avoid the overhead associated with fragmentation and reassembly
(principa=
lly
> memory buffering) which is a good thing. When reassembled, the os
should
> deliver a datagram as a complete entity in one go (irrespective of the
mt=
u
> size, assuming that the datagram falls within the maximum datagram
size
> defined for the stack). If the sender doesn't send a message as a
single
> datagram, then the whole thing falls apart because effectively you are
th=
en
> doing fragmentation and reassembly at the application layer, and that
won=
't
> work because the ordering across datagrams is not guaranteed and
individu=
al
> datagrams may get lost.
>
>
> If anything goes wrong (eg, missing fragment) the whole datagram is
> dropped. I can=92t see how packet re-ordering can happen on a single
LAN =
for
> broadcast UDP =96 there are no multiple paths and no retry mechanism.
> Certainly never observed it =96 I assume the stack would again just
drop =
the
> entire datagram.
>
>
> Re-ordering of datagrams can occur for multiple reasons on a single
lan. =
A
> sender may send individual UDP packets in any order it chooses. This
> commonly occurs with fragmented packets originating from a
multi-threaded
> sender, which can be interleaved with smaller, non-fragmented
datagrams a=
s
> required (optimising transient memory use, as soon as they are sent,
the
> buffer can be released). A switch is not obliged to retransmit packets
in
> the order in which they are received. And most fundamentally, the
specs d=
o
> not require UDP packets to be ordered so, even if you don't observe
it, i=
t
> *can* happen, and sooner or later interoperability issues will arise
if
> the working assumption is made that they always arrive in order.
>
>
>
> A bigger issue for me, and the reason for me experimenting a few times
wi=
th
> TCP stream serving from hubs, is datagram loss over WiFi networks.
This i=
s
> greatly accentuated for UDP when you use broadcast (as we do) from
wired =
to
> wireless (fine the other way as it=92s not really a broadcast packet
till=
it
> gets to the AP) as the access point and NIC can not longer apply their
> ack/nak procedure at the transport level. I commonly see xAP datagram
los=
s
> rates from wired to wireless connections of 20%. So I=92d like us to
agre=
e on
> a standard transport wrapper for TCP streams which a lot of platforms
wou=
ld
> find useful.
>
>
>
> I'd suggest using the same framing as the "transport
wrapper", as this
> then allows for code to be shared across transports. If xAP was
extended =
to
> support TCP, then that should also include a formal discovery
mechanism b=
y
> which the IP address/characteristics of the hub can be discovered
(over U=
DP
> xAP?)
>
> Patrick
>
>
> *From:* xAP_developer@xxxxxxx [mailto:
> xAP_developer@xxxxxxx] *On Behalf Of *Patrick Lidstone
> *Sent:* 14 September 2009 14:19
> *To:* xAP_developer@xxxxxxx
> *Subject:* Re: [xAP_developer] xAP EOM identifier in xAP v1.3
>
>
>
>
>
> So the xAP delimiters for serial are defined in the 1.2 xAP spec here:
>
> http://www.xapautomation.org/index.php?title=3DProtocol_definition#Transp=
ort_Wrapper
>
> To the best of my knowledge, the MTU size for an ethernet frame is
1518
> bytes, which leads to a UDP packet MTU of 1500 bytes and this is the
size
> that is adopted by the majority of operating systems. Internet routers
(i=
.e.
> ISPs) sometimes use an MTU of 576 bytes, but this wouldn't be relevant
to
> xAP since the traffic doesn't pass over the wider net, or if it does,
it'=
s
> generally gatewayed via a TCP/IP connection.
>
> If a device is receiving fragmented UDP packets, I think the same
issues
> arise as those related to extending the xAP message size beyond 1500
byte=
s -
> what happens if a fragment gets discarded.
>
> If you take the scenario:
>
> Part 1(a), Part 1(b), Part 2(a), Part 2(b), Part 3(a), Part 3(b)
>
> --- first there is no guarantee that the parts will be delivered in
order=
,
> and second, if part 1(b) was dropped, and you were blindly assembling
> messages based on the proposed double-0a terminator, you'd end up with
a
> message comprising part 1(a), 2(a) and 2(b) which is not only
obviously
> corrupt, but also possibly larger than the maximum xAP message size,
blow=
ing
> away your buffers.
>
> I think the solution is to probably parse incoming messages on the
fly,
> byte-by-byte. You can then at least reset your state when you
encounter t=
he
> xap-header, and if you count open and close curly braces, you can tell
wh=
en
> you have an apparently complete message. This won't solve the issue of
UD=
P
> fragments being potentially received out of order, but so long as we
are
> dealing with a single LAN, and fragmentation occurs at the receiver,
we w=
ill
> be ok I think.
>
> It is absolutely possible for UDP packets to be discarded, and the way
we
> deal with this in xAP is to accept that this can happen to xAP
messages, =
and
> layer application level acknowledgements where knowing that a message
has
> been received is critically important - whether explicitly or
implicitly
> through status messages. There are various schemes that could be
adopted =
to
> allow a receiver to detect lost messages (e.g. sequence numbering),
but t=
hey
> quickly become quite onerous, and assume that the originator keeps a
copy=
of
> the original message or is able to reconstruct it - which is
non-trivial =
for
> the many xAP nodes.
>
> Perhaps you can share more of the specific details of the device(s) in
> question (manufacturer, docs, o/s etc), and their specific behaviour,
whi=
ch
> seems a bit anomalous?
>
> Patrick
>
> 2009/9/13 Kevin Hawkins <yahoogroupskh@xxxxxxx>
>
> One of the issues seems to be that there is conflicting views as to
the
> length of a a UDP data packet payload. Some people cite 500 or 512
> characters and some 1500. Regardless in some low memory/performance
> devices it is being reported, that even with UDP, packets are being
> received from the buffer either truncated or appended back to back.
> The latter I assume is due to the speed of the device in servicing the
> buffer.
>
> We have an opportunity to protect against this with v1.3 and the
double
> '0A' seems the most compatible. I would be loathe to support
anything
> that wasn't backward compatible.
>
> K
>
>
> Patrick Lidstone wrote:
> >
> >
> > I will dig it out - it included an optional checksum I think, and
IIRC
> > was framed by stx and etx (a kind of pseudo industry standard). I
> > certainly used it with the PIC serial stuff and the xAP-serial
bridge.
> > Re.: long message truncation and concatenation: If we need to
support
> > messages that are larger than one UDP packet, then there are
> > additional complexities and the proposed scheme won't work as
intended
> > as the ordering of UDP messages is not guaranteed. I'm happy to
help
> > refine a spec to support these capabilities, but it is moving
away
> > from the basic ethos of xAP somewhat, as devices would have to be
able
> > to buffer received messages, and that raises the bar
considerably.
> > Perhaps there is scope for co-existence of a long and standard
message
> > protocol though?
> >
> > Patrick
> >
> > 2009/9/13 Kevin Hawkins <yahoogroupskh@xxxxxxx
>
> > <mailto:yahoogroupskh@xxxxxxx>>
>
> >
> > ... Oh ... where is that in the spec ? it might be all we
need.
> >
> > This is also tied in with some aspects of long message
truncatio=
n
> > and concatenation of messages received in UDP receive buffers
> > though...
> >
> > K
> >
> > Patrick Lidstone wrote:
> > >
> > >
> > > The original xap spec provides extensions for framing a
message
> over
> > > async serial which also delimit the start of the message
- you
> don't
> > > need this 'hack' if you follow the original spec for
non-UDP
> > transports.
> > >
> > > Patrick
> > >
> > > 2009/9/13 Kevin Hawkins <yahoogroupskh@xxxxxxx
> > <mailto:yahoogroupskh@xxxxxxx>
>
> > > <mailto:yahoogroupskh@xxxxxxx
>
> > <mailto:yahoogroupskh@xxxxxxx>>>
> > >
> > > We have been asked on several occasions how to
detect the
> > end of a
> > > xAP messager as there is no unique EOM character.
Typically
> > in any
> > > reasonable sized packet structured transport eg UDP
then the
> > packet
> > > provides such an indication but on systems with
small packets
> or
> > > non eg
> > > asynchronous serial this is not useable.
> > >
> > > In discussing this with the specification team we
must
> > consider
> > > backwards compatability and so we do not wish to
alter the
> > > specification
> > > to include a unique EOM character. What we do
propose
> > however is that
> > > xAP v1.3 will specify that all messages should end
with two
> > > consecutive
> > > chr(10)'s immediately after the closing '}'
> > >
> > > ie ..... 7D 0A 0A
> > >
> > > Some apps, even v1.2 ones, already do this. We
don't
> > believe this
> > > will cause any backwards compatibility issues and it
will
> > always be
> > > unique within a xAP message.
> > >
> > > So, in developing xAP v1.3 apps could you therefore
append
> > two 0A's
> > > at the end of your messages , and of course handle
incoming
> > messages
> > > containing such.
> > >
> > > K
> > >
> > >
> > > ------------------------------------
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > > mailto:xAP_developer-fullfeatured@xxxxxxx
> > <mailto:xAP_developer-fullfeatured@xxxxxxx>
> > > <mailto:xAP_developer-fullfeatured@xxxxxxx
> > <mailto:xAP_developer-fullfeatured@xxxxxxx>>
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> > mailto:xAP_developer-fullfeatured@xxxxxxx
> > <mailto:xAP_developer-fullfeatured@xxxxxxx>
> >
> >
> >
> >
> >
> >
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>=20
>
--00c09fd1aeac46f5260473c2f47b
Content-Type: text/html; charset=windows-1252
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** -->
Cool!<br><br>I'm not sure the transport wrapper over
TCP 'breaks ev=
erything' - I've used it for TCP routing of xAP over the
internet f=
ramed using the transport wrapper for several years now (I even demoed it
a=
s a means of remotely accessing my home intranet via xAP at the inaugural
H=
A weekend meet many moons ago), but perhaps I'm missing something
from =
your requirements? All the tcp hub has to do is strip off the start and
end=
delimiter before rebroadcast, and likewise frame any received udp messages=
with an <stx>, <etx> if operating
bi-directionally. Admittedly=
it's an additional (minimal) cost that isn't present with
the doub=
le-0A scheme, but the benefits of being able to detect the start of frame,
=
and the benefits of being able to apply this approach to any async
transpor=
t, not just tcp/ip, outweigh that in my mind. And it is in the spec
already=
;-)<br>
<br>Personally, I don't see a need for a delimiter at the end
of a mess=
age in UDP xAP. I'm sure I'm going to be outvoted, but look
at all =
the other UDP protocols out there - it's not common practice
because it=
's not technically necessary, and as such it's just adding
unnecess=
ary cruft to xAP!<br>
<br>Cheers<br>Patrick<br><br><br><div
class=3D"gmail_quote">2009/9/17 Edwar=
d Pearson <span dir=3D"ltr"><<a href=3D"mailto:edward.mailgroup@blueyond=
er.co.uk">edward.mailgroup@xxxxxxx</a>></span><br><blockquote
c=
lass=3D"gmail_quote" style=3D"border-left: 1px solid
rgb(204, 204, 204); ma=
rgin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
=20=20=20=20=20=20=20=20
<div bgcolor=3D"white" link=3D"blue"
vlink=3D"purple" lang=3D"EN-GB">
<br><br>
<div>
<p><span style=3D"font-size: 11pt; color: rgb(31, 73,
125);">You=92re right=
, to get a connection in good time that=92s
not statically configured it=92d need a request/offer message
pair.</span><=
/p>
<p><span style=3D"font-size: 11pt; color: rgb(31, 73,
125);">=A0</span></p>
<p><span style=3D"font-size: 11pt; color: rgb(31, 73,
125);">The experiment=
al hub I have here is designed to address one
specific problem only =96 unreliability over WiFi.</span></p>
<p><span style=3D"font-size: 11pt; color: rgb(31, 73,
125);">In runs as a m=
aster slave arrangement. In master mode it accepts
incoming tcp connections on port 3639. In slave mode (deployed on the WiFi
machine) it=92s configured (statically) with the IP address or hostname of
the master hub to which it connects over tcp. The tcp connection is used
one-way only, from master to slave. The master forwards all xAP messages it
receives (on udp) to all its local udp clients (as usual) and to any
connec=
ted
tcp clients. The slave forwards all messages received on its tcp
connection=
to
its local clients on udp. Works a treat. Now I can lie on the sofa
debuggin=
g Viewer
v4 (it=92ll be out really, really soon now I promise) on my WiFi laptop
wit=
hout
wondering where 15% of the messages have gone.</span></p>
<p><span style=3D"font-size: 11pt; color: rgb(31, 73,
125);">=A0</span></p>
<p><span style=3D"font-size: 11pt; color: rgb(31, 73,
125);">I mention all =
this mainly (and at risk of getting back to Kevin=92s
original point of this thread which I=92m feeling guilty of hijacking
horribly) because I needed to address the problem of the segregation =A0of
messages in a stream to get this to work. So I experimented with several
schemes=A0 getting a good feel for the practical pro=92s and cons of
each. Initially I went for the STX/ETX method from the transport wrapper
si=
nce
it=92s what=92s in the existing spec (but opting out of the CRC). Later
I used the double LF termination. The transport wrapper is somewhat easier
=
to
work with. For instance, it=92s easier to re-sync to the a message start
with transport wrapper; just wait for the next STX (a single byte), vs.
nee=
ding
match all of =93xap-[headerhbeat]<lf>=94. Message ends are
similar: ETX (1 byte) vs <lf><lf> (2 bytes).
=A0But all this is=
irrelevant
in the udp world. Introducing STX/ETX here would break everything while
dou=
ble <lf>
is nicely backwards compatible.</span></p>
<p><span style=3D"font-size: 11pt; color: rgb(31, 73,
125);">=A0</span></p>
<p><span style=3D"font-size: 11pt; color: rgb(31, 73,
125);">(and finally, =
my point relevant to the thread start)</span></p>
<p><span style=3D"font-size: 11pt; color: rgb(31, 73,
125);">=A0</span></p>
<p><span style=3D"font-size: 11pt; color: rgb(31, 73,
125);">I don=92t thin=
k double <lf> is the right solution for
Kevin=92s developers=92 wireless app problem; it=92d help them out somewhat
but I think it more than likely that it=92s =91papering over=92 a
bug in or around their network stack. But there is a valid need lurking in
=
here;
without message-level delimiting in the original spec, implementers of xAP
=
commonly
run up against the problem of knowing where the end of a message is while
parsing messages. The double <lf> definitely helps here. So
given tha=
t it=92s
easy to add, helps in some folks, eases adoption and causes no backwards
co=
mpatibility
issues, I=92m happy that it should go into the v1.3
spec.</span></p>
<p><span style=3D"font-size: 11pt; color: rgb(31, 73,
125);">=A0</span></p>
<div style=3D"border-style: none none none solid; border-color:
-moz-use-te=
xt-color -moz-use-text-color -moz-use-text-color blue; border-width:
medium=
medium medium 1.5pt; padding: 0cm 0cm 0cm 4pt;">
<div>
<div style=3D"border-style: solid none none; border-color: rgb(181,
196, 22=
3) -moz-use-text-color -moz-use-text-color; border-width: 1pt medium
medium=
; padding: 3pt 0cm 0cm;">
<p><b><span style=3D"font-size: 10pt;"
lang=3D"EN-US">From:</span></b><span=
style=3D"font-size: 10pt;" lang=3D"EN-US"> <a
href=3D"mailto:xAP_developer=
@yahoogroups.com"
target=3D"_blank">xAP_developer@xxxxxxx</a>
[mailto:<a href=3D"mailto:xAP_developer@xxxxxxx";
target=3D"_blank">=
xAP_developer@xxxxxxx</a>] <b>On Behalf Of </b>Patrick
Lidstone<br>
<b>Sent:</b> 16 September 2009
12:00<div><div></div><div
class=3D"h5"><br>
<b>To:</b> <a href=3D"mailto:xAP_developer@xxxxxxx";
target=3D"_blan=
k">xAP_developer@xxxxxxx</a><br>
<b>Subject:</b> Re: [xAP_developer] xAP EOM identifier in xAP
v1.3</div></d=
iv></span></p>
</div>
</div><div><div></div><div
class=3D"h5">
<p>=A0</p>
<p>=A0 </p>
<div>
<div>
<div>
<p style=3D"margin-bottom: 12pt;">I agree that checksums
are not appropriat=
e to
TCP connections, the transport wrapper already designates them as
optional.=
<br>
<br>
I don't think hubs currently send heartbeats? If they do,
it's not =
explicit in
the spec. (Mine doesn't). We also need a mechanism to differentiate
bet=
ween
multiple hubs (since most people will generally run at least one hub per
vm=
). <br>
<br>
Is a TCP hub going to relay all traffic to all TCP endpoints? That
won'=
t scale
very well... but it's also not clear how the filtering etc. will
work. =
Administering
filters manually works fine for the odd serial segment, but it's
not go=
ing to
be viable for a large number of endpoints.<br>
<br>
Heartbeats are broadcast every minute or so typically, so that's
going =
to
result in start up times of up to two minutes for a tcp end point. Is that
acceptable? If not, do we reduce the new tcp hub heartbeat interval? Or is
there a mechanism for an endpoint to poke a hub and elicit a
heartbeat?<br>
<br>
And lastly, is there merit in some kind of referrer system to allow for
load-balancing and automated failover of tcp connections across more than
o=
ne
hub? If so, how would this work?<br>
<br>
Patrick</p>
<div>
<p>2009/9/15 Edward Pearson <<a href=3D"mailto:edward.mailgroup@blueyond=
er.co.uk"
target=3D"_blank">edward.mailgroup@xxxxxxx</a>></p>
<div>
<p style=3D"margin-bottom: 12pt;">=A0</p>
<div>
<p><span style=3D"font-size: 11pt; color: rgb(31, 73,
125);">I don=92t mean=
that packet
fragmentation or re-ordering are myths =96 just that when dealing with xAP
at the IP stack (socket) interface you are dealing with datagrams not data
packets so you don=92t need to worry about those packet aspects. There was
a design decision to limit xAP datagrams to 1500 bytes to improve the
likel=
y
coverage of correctly sent datagrams in a world of IP stacks of varying
quality. It=92s no more important than that. Readers of the spec seem to
attach more importance to it than it needs (there=92s the myth aspect).=A0
To program xAP you don=92t need to worry about fragmentation and reordering
=96 just keep your datagrams 1500 bytes or less and let the stack do its
thing.</span></p>
<p><span style=3D"font-size: 11pt; color: rgb(31, 73,
125);">=A0</span></p>
<p><span style=3D"font-size: 11pt; color: rgb(31, 73,
125);">Sometimes an a=
pp goes a bit
wild (xAP news has occasionally been a useful test source) and big xAP
mess=
ages
are generated =96 and they get delivered too! It=92s normally the input
buffer of the receiving app (eg hub) that breaks
first.</span></p>
<p><span style=3D"font-size: 11pt; color: rgb(31, 73,
125);">=A0</span></p>
<p><span style=3D"font-size: 11pt; color: rgb(31, 73,
125);">On the tcp fra=
ming, I=92d
suggest that implementing the CRC part (irrelevant on a reliable stream)
is=
a
waste of most people=92s time; by far more use will be made of tcp than any
kind of serial/485/etc networks so they=92d be sharing development of an
implementation with nobody.</span></p>
<p><span style=3D"font-size: 11pt; color: rgb(31, 73,
125);">=A0</span></p>
<p><span style=3D"font-size: 11pt; color: rgb(31, 73,
125);">Discovery can =
be done simply
with the existing hub heartbeat message. Just need to agree on an extra
blo=
ck
that advertises the port number of the tcp service =96 which I assume, by
default would be 3639.</span></p>
<p><span style=3D"font-size: 11pt; color: rgb(31, 73,
125);">=A0</span></p>
<p><span style=3D"font-size: 11pt; color: rgb(31, 73,
125);">Having read th=
e 802.11 spec, I
now understand why broadcast udp from an AP to a NIC is so un-reliable. And
ad-hoc mode is a real disaster!</span></p>
<p><span style=3D"font-size: 11pt; color: rgb(31, 73,
125);">=A0</span></p>
<div style=3D"border-style: none none none solid; border-color:
-moz-use-te=
xt-color -moz-use-text-color -moz-use-text-color windowtext; border-width:
=
medium medium medium 1.5pt; padding: 0cm;">
<div>
<div style=3D"border-style: solid none none; border-color:
windowtext -moz-=
use-text-color -moz-use-text-color; border-width: 1pt medium medium;
paddin=
g: 0cm;">
<p><b><span style=3D"font-size: 10pt;"
lang=3D"EN-US">From:</span></b><span=
style=3D"font-size: 10pt;" lang=3D"EN-US"> <a
href=3D"mailto:xAP_developer=
@yahoogroups.com"
target=3D"_blank">xAP_developer@xxxxxxx</a>
[mailto:<a href=3D"mailto:xAP_developer@xxxxxxx";
target=3D"_blank">=
xAP_developer@xxxxxxx</a>]
<b>On Behalf Of </b>Patrick Lidstone<br>
<b>Sent:</b> 15 September 2009 14:15</span></p>
<div>
<div>
<p><span style=3D"font-size: 10pt;"
lang=3D"EN-US"><br>
<b>To:</b> <a href=3D"mailto:xAP_developer@xxxxxxx";
target=3D"_blan=
k">xAP_developer@xxxxxxx</a><br>
<b>Subject:</b> Re: [xAP_developer] xAP EOM identifier in xAP
v1.3</span></=
p>
</div>
</div>
</div>
</div>
<div>
<div>
<p>=A0</p>
<p>=A0 </p>
<div>
<div>
<div>
<p>Hi Edward,<br>
Please see in-line responses...</p>
<div>
<p>2009/9/15 Edward Pearson <<a href=3D"mailto:edward.mailgroup@blueyond=
er.co.uk"
target=3D"_blank">edward.mailgroup@xxxxxxx</a>></p>
<div>
<p>=A0</p>
<div>
<p><span style=3D"font-size: 11pt; color: rgb(31, 73,
125);">The double 0x0=
a terminator
works for me, it=92s simple to implement =96 already done for my
stuff.</sp=
an></p>
<p><span style=3D"font-size: 11pt; color: rgb(31, 73,
125);">=A0</span></p>
</div>
</div>
<div>
<p>...but it isn't robust unless the message is sent as a
single datagr=
am, and
if it is sent as a single datagram, the os should deliver it as such --
and=
if
it doesn't, adding an eom marker isn't going to help.
</p>
</div>
<blockquote style=3D"border-style: none none none solid;
border-color: -moz=
-use-text-color -moz-use-text-color -moz-use-text-color windowtext;
border-=
width: medium medium medium 1pt; padding: 0cm; margin-top: 5pt;
margin-bott=
om: 5pt;">
<div>
<div>
<p><span style=3D"font-size: 11pt; color: rgb(31, 73,
125);">For reliable s=
treams, such as
TCP, I generally frame the messages with STX and
ETX.</span></p>
<p><span style=3D"font-size: 11pt; color: rgb(31, 73,
125);">=A0</span></p>
<p><span style=3D"font-size: 11pt; color: rgb(31, 73,
125);">I thought all =
this business
about 1500 bytes was somewhat urban myth (at least as it applies to xAP).
T=
he
data packet size is not what=92s important; it=92s how the particular
IP stack implementation deals with >datagrams< that=92s the
key.
=A0</span></p>
</div>
</div>
</blockquote>
<div>
<p><br>
I don't understand what you are syaing here? The data packet size
is
inextricably linked to the IP stack. What aspect is it that you consider
to=
be
an urban myth?<br>
=A0</p>
</div>
<blockquote style=3D"border-style: none none none solid;
border-color: -moz=
-use-text-color -moz-use-text-color -moz-use-text-color windowtext;
border-=
width: medium medium medium 1pt; padding: 0cm; margin-top: 5pt;
margin-bott=
om: 5pt;">
<div>
<div>
<p><span style=3D"font-size: 11pt; color: rgb(31, 73,
125);">I only have ex=
perience of the
two most recent Windows stacks (XP and Vista) which I agree are likely more
capable than old embedded stacks. My experiments with Wireshark show that
t=
hose
stacks will happily deal with fragmentation and defragmentation. 64KB in a
single datagram? No problem if your receive buffer is long enough (even if
=
you
force a small MTU).</span></p>
</div>
</div>
</blockquote>
<div>
<p>Yes, agreed, OSes perform fragmentation for you. The individual
fragment=
s
have a maximum size as determined by the MTU. For pragmatic, practical
reas=
ons,
xAP needs to define a maximum overall message size, and for
convenience'=
;s sake
that was set as equal to the 'standard' MTU size. Devices
which use=
a smaller
MTU <i>should </i>fragment and reassemble seamlessly provided
that the corr=
ect
socket options have been set to define the maximum UDP packet size. By
elec=
ting
to use a single MTU's worth of data, we we avoid the overhead
associate=
d with
fragmentation and reassembly (principally memory buffering) which is a good
thing. When reassembled, the os should deliver a datagram as a complete
ent=
ity
in one go (irrespective of the mtu size, assuming that the datagram falls
within the maximum datagram size defined for the stack). If the sender
does=
n't
send a message as a single datagram, then the whole thing falls apart
becau=
se
effectively you are then doing fragmentation and reassembly at the
applicat=
ion
layer, and that won't work because the ordering across datagrams is
not
guaranteed and individual datagrams may get lost.<br>
=A0</p>
</div>
<blockquote style=3D"border-style: none none none solid;
border-color: -moz=
-use-text-color -moz-use-text-color -moz-use-text-color windowtext;
border-=
width: medium medium medium 1pt; padding: 0cm; margin-top: 5pt;
margin-bott=
om: 5pt;">
<div>
<div>
<p><span style=3D"font-size: 11pt; color: rgb(31, 73,
125);">If anything go=
es wrong (eg,
missing fragment) the whole datagram is dropped. I can=92t see how packet
re-ordering can happen on a single LAN for broadcast UDP =96 there are no
multiple paths and no retry mechanism. Certainly never observed it =96 I
assume the stack would again just drop the entire
datagram.</span></p>
</div>
</div>
</blockquote>
<div>
<p><br>
Re-ordering of datagrams can occur for multiple reasons on a single lan. A
sender may send individual UDP packets in any order it chooses. This
common=
ly
occurs with fragmented packets originating from a multi-threaded sender,
wh=
ich
can be interleaved with smaller, non-fragmented datagrams as required
(optimising transient memory use, as soon as they are sent, the buffer can
=
be
released). A switch is not obliged to retransmit packets in the order in
wh=
ich
they are received. And most fundamentally, the specs do not require UDP
pac=
kets
to be ordered so, even if you don't observe it, it
<i>can</i> happen, a=
nd
sooner or later interoperability issues will arise if the working
assumptio=
n is
made that they always arrive in order.</p>
</div>
<blockquote style=3D"border-style: none none none solid;
border-color: -moz=
-use-text-color -moz-use-text-color -moz-use-text-color windowtext;
border-=
width: medium medium medium 1pt; padding: 0cm; margin-top: 5pt;
margin-bott=
om: 5pt;">
<div>
<div>
<p><span style=3D"font-size: 11pt; color: rgb(31, 73,
125);">=A0</span></p>
<p><span style=3D"font-size: 11pt; color: rgb(31, 73,
125);">A bigger issue=
for me, and the
reason for me experimenting a few times with TCP stream serving from hubs,
=
is
datagram loss over WiFi networks. This is greatly accentuated for UDP when
=
you
use broadcast (as we do) from wired to wireless (fine the other way as
it=92s not really a broadcast packet till it gets to the AP) as the access
point and NIC can not longer apply their ack/nak procedure at the transport
level. I commonly see xAP datagram loss rates from wired to wireless
connections of 20%. So I=92d like us to agree on a standard transport
wrapper for TCP streams which a lot of platforms would find
useful.</span><=
/p>
<p><span style=3D"font-size: 11pt; color: rgb(31, 73,
125);">=A0</span></p>
</div>
</div>
</blockquote>
<div>
<p>I'd suggest using the same framing as the
"transport wrapper&qu=
ot;, as
this then allows for code to be shared across transports. If xAP was
extend=
ed
to support TCP, then that should also include a formal discovery mechanism
=
by
which the IP address/characteristics of the hub can be discovered (over UDP
xAP?)<br>
<br>
Patrick<br>
=A0</p>
</div>
<blockquote style=3D"border-style: none none none solid;
border-color: -moz=
-use-text-color -moz-use-text-color -moz-use-text-color windowtext;
border-=
width: medium medium medium 1pt; padding: 0cm; margin-top: 5pt;
margin-bott=
om: 5pt;">
<div>
<div>
<div style=3D"border-style: none none none solid; border-color:
-moz-use-te=
xt-color -moz-use-text-color -moz-use-text-color windowtext; border-width:
=
medium medium medium 1.5pt; padding: 0cm;">
<div>
<div style=3D"border-style: solid none none; border-color:
windowtext -moz-=
use-text-color -moz-use-text-color; border-width: 1pt medium medium;
paddin=
g: 0cm;">
<p><b><span style=3D"font-size: 10pt;"
lang=3D"EN-US">From:</span></b><span=
style=3D"font-size: 10pt;" lang=3D"EN-US"> <a
href=3D"mailto:xAP_developer=
@yahoogroups.com"
target=3D"_blank">xAP_developer@xxxxxxx</a>
[mailto:<a href=3D"mailto:xAP_developer@xxxxxxx";
target=3D"_blank">=
xAP_developer@xxxxxxx</a>]
<b>On Behalf Of </b>Patrick Lidstone<br>
<b>Sent:</b> 14 September 2009 14:19<br>
<b>To:</b> <a href=3D"mailto:xAP_developer@xxxxxxx";
target=3D"_blan=
k">xAP_developer@xxxxxxx</a><br>
<b>Subject:</b> Re: [xAP_developer] xAP EOM identifier in xAP
v1.3</span></=
p>
</div>
</div>
<div>
<div>
<p>=A0</p>
<p>=A0 </p>
<div>
<div>
<div>
<p>So the xAP delimiters for serial are defined in the 1.2 xAP spec
here:<b=
r>
<a href=3D"http://www.xapautomation.org/index.php?title=3DProtocol_definiti=
on#Transport_Wrapper" target=3D"_blank">http://www.xapautomation.org/index.=
php?title=3DProtocol_definition#Transport_Wrapper</a><br>
<br>
To the best of my knowledge, the MTU size for an ethernet frame is 1518
byt=
es,
which leads to a UDP packet MTU of 1500 bytes and this is the size that is
adopted by the majority of operating systems. Internet routers (i.e. ISPs)
sometimes use an MTU of 576 bytes, but this wouldn't be relevant to
xAP=
since
the traffic doesn't pass over the wider net, or if it does,
it's ge=
nerally
gatewayed via a TCP/IP connection.<br>
<br>
If a device is receiving fragmented UDP packets, I think the same issues
ar=
ise as
those related to extending the xAP message size beyond 1500 bytes - what
happens if a fragment gets discarded.<br>
<br>
If you take the scenario:<br>
<br>
Part 1(a), Part 1(b), Part 2(a), Part 2(b), Part 3(a), Part 3(b)<br>
<br>
--- first there is no guarantee that the parts will be delivered in order,
=
and
second, if part 1(b) was dropped, and you were blindly assembling messages
based on the proposed double-0a terminator, you'd end up with a
message
comprising part 1(a), 2(a) and 2(b) which is not only obviously corrupt,
bu=
t also
possibly larger than the maximum xAP message size, blowing away your
buffer=
s.<br>
<br>
I think the solution is to probably parse incoming messages on the fly,
byte-by-byte. You can then at least reset your state when you encounter the
xap-header, and if you count open and close curly braces, you can tell
when=
you
have an apparently complete message. This won't solve the issue of
UDP
fragments being potentially received out of order, but so long as we are
dealing with a single LAN, and fragmentation occurs at the receiver, we
wil=
l be
ok I think.<br>
<br>
It is absolutely possible for UDP packets to be discarded, and the way we
d=
eal
with this in xAP is to accept that this can happen to xAP messages, and
lay=
er
application level acknowledgements where knowing that a message has been
received is critically important - whether explicitly or implicitly through
status messages. There are various schemes that could be adopted to allow a
receiver to detect lost messages (e.g. sequence numbering), but they
quickl=
y
become quite onerous, and assume that the originator keeps a copy of the
original message or is able to reconstruct it - which is non-trivial for
th=
e
many xAP nodes.<br>
<br>
Perhaps you can share more of the specific details of the device(s) in
ques=
tion
(manufacturer, docs, o/s etc), and their specific behaviour, which seems a
=
bit
anomalous?<br>
<br>
Patrick</p>
<div>
<p>2009/9/13 Kevin Hawkins <<a href=3D"mailto:yahoogroupskh@xxxxxxx=
om"
target=3D"_blank">yahoogroupskh@xxxxxxx</a>></p>
<p>One of the issues seems to be that there is conflicting views as
to the<=
br>
length of a a UDP data packet payload. =A0Some people cite 500 or
512<br>
characters and some 1500. =A0Regardless in some low
memory/performance<br>
devices it is being reported, that even with UDP, =A0packets are
being<br>
received from the buffer either truncated or appended back to
back.<br>
The latter I assume is due to the speed of the device in servicing
the<br>
buffer.<br>
<br>
We have an opportunity to protect against this with v1.3 and the
double<br>
'0A' seems the most compatible. =A0 I would be loathe to
support an=
ything<br>
that wasn't backward compatible.<br>
<br>
=A0 K</p>
<div>
<p><br>
Patrick Lidstone wrote:<br>
><br>
><br>
> I will dig it out - it included an optional checksum I think, and
IIRC=
<br>
> was framed by stx and etx (a kind of pseudo industry standard).
I<br>
> certainly used it with the PIC serial stuff and the xAP-serial
bridge.=
<br>
> Re.: long message truncation and concatenation: If we need to
support<=
br>
> messages that are larger than one UDP packet, then there
are<br>
> additional complexities and the proposed scheme won't work
as inte=
nded<br>
> as the ordering of UDP messages is not guaranteed. I'm
happy to he=
lp<br>
> refine a spec to support these capabilities, but it is moving
away<br>
> from the basic ethos of xAP somewhat, as devices would have to be
able=
<br>
> to buffer received messages, and that raises the bar
considerably.<br>
> Perhaps there is scope for co-existence of a long and standard
message=
<br>
> protocol though?<br>
><br>
> Patrick<br>
><br>
> 2009/9/13 Kevin Hawkins <<a href=3D"mailto:yahoogroupskh@googlemail=
.com"
target=3D"_blank">yahoogroupskh@xxxxxxx</a></p>
</div>
<p>> <mailto:<a href=3D"mailto:yahoogroupskh@xxxxxxx";
target=
=3D"_blank">yahoogroupskh@xxxxxxx</a>>></p>
<div>
<p>><br>
> =A0 =A0 ... Oh ... where is that in the spec ? =A0it might be all
we need.<br>
><br>
> =A0 =A0 =A0 =A0This is also tied in with some aspects of long
message truncation<br>
> =A0 =A0 and concatenation of messages received in UDP receive
buffers<br>
> =A0 =A0 though...<br>
><br>
> =A0 =A0 =A0K<br>
><br>
> =A0 =A0 Patrick Lidstone wrote:<br>
> =A0 =A0 ><br>
> =A0 =A0 ><br>
> =A0 =A0 > The original xap spec provides extensions for
framing a
message over<br>
> =A0 =A0 > async serial which also delimit the start of the
message - you don't<br>
> =A0 =A0 > need this 'hack' if you follow
the original spec =
for
non-UDP<br>
> =A0 =A0 transports.<br>
> =A0 =A0 ><br>
> =A0 =A0 > Patrick<br>
> =A0 =A0 ><br>
> =A0 =A0 > 2009/9/13 Kevin Hawkins <<a
href=3D"mailto:yahoogroups=
kh@xxxxxxx"
target=3D"_blank">yahoogroupskh@xxxxxxx</a><br>
> =A0 =A0 <mailto:<a href=3D"mailto:yahoogroupskh@xxxxxxx";
tar=
get=3D"_blank">yahoogroupskh@xxxxxxx</a>></p>
</div>
<p>> =A0 =A0 > <mailto:<a href=3D"mailto:yahoogroupskh@googlemail.=
com"
target=3D"_blank">yahoogroupskh@xxxxxxx</a></p>
<div>
<div>
<p>> =A0 =A0 <mailto:<a href=3D"mailto:yahoogroupskh@xxxxxxx";
=
target=3D"_blank">yahoogroupskh@xxxxxxx</a>>>><br>
> =A0 =A0 ><br>
> =A0 =A0 > =A0 =A0 =A0 We have been asked on several
occasions how to detect the<br>
> =A0 =A0 end of a<br>
> =A0 =A0 > =A0 =A0 xAP messager as there is no unique EOM
character. =A0Typically<br>
> =A0 =A0 in any<br>
> =A0 =A0 > =A0 =A0 reasonable sized packet structured
transport eg UDP then the<br>
> =A0 =A0 packet<br>
> =A0 =A0 > =A0 =A0 provides such an indication but on
systems with small packets or<br>
> =A0 =A0 > =A0 =A0 non eg<br>
> =A0 =A0 > =A0 =A0 asynchronous serial this is not
useable.<br>
> =A0 =A0 ><br>
> =A0 =A0 > =A0 =A0 =A0 In discussing this with the
specification team we must<br>
> =A0 =A0 consider<br>
> =A0 =A0 > =A0 =A0 backwards compatability and so we do not
wish to alter the<br>
> =A0 =A0 > =A0 =A0 specification<br>
> =A0 =A0 > =A0 =A0 to include a unique EOM character.
=A0What we do propose<br>
> =A0 =A0 however is that<br>
> =A0 =A0 > =A0 =A0 xAP v1.3 will specify that all messages
should end with two<br>
> =A0 =A0 > =A0 =A0 consecutive<br>
> =A0 =A0 > =A0 =A0 chr(10)'s immediately after the
closing
'}'<br>
> =A0 =A0 ><br>
> =A0 =A0 > =A0 =A0 ie =A0..... 7D 0A 0A<br>
> =A0 =A0 ><br>
> =A0 =A0 > =A0 =A0 =A0Some apps, even v1.2 ones,
=A0already do this. =A0We don't<br>
> =A0 =A0 believe this<br>
> =A0 =A0 > =A0 =A0 will cause any backwards compatibility
issues and it will<br>
> =A0 =A0 always be<br>
> =A0 =A0 > =A0 =A0 unique within a xAP message.<br>
> =A0 =A0 ><br>
> =A0 =A0 > =A0 =A0 =A0So, in developing xAP v1.3 apps
could you therefore append<br>
> =A0 =A0 =A0two 0A's<br>
> =A0 =A0 > =A0 =A0 at the end of your messages , and of
course handle incoming<br>
> =A0 =A0 messages<br>
> =A0 =A0 > =A0 =A0 containing such.<br>
> =A0 =A0 ><br>
> =A0 =A0 > =A0 =A0 =A0 K<br>
> =A0 =A0 ><br>
> =A0 =A0 ><br>
> =A0 =A0 > =A0 =A0
------------------------------------<br>
> =A0 =A0 ><br>
> =A0 =A0 > =A0 =A0 Yahoo! Groups Links<br>
> =A0 =A0 ><br>
> =A0 =A0 ><br>
> =A0 =A0 > =A0 =A0 =A0 =A0mailto:<a href=3D"mailto:xAP_developer-ful=
lfeatured@xxxxxxx"
target=3D"_blank">xAP_developer-fullfeatured@yah=
oogroups.com</a><br>
> =A0 =A0 <mailto:<a href=3D"mailto:xAP_developer-fullfeatured@yahoog=
roups.com"
target=3D"_blank">xAP_developer-fullfeatured@xxxxxxx</a>=
><br>
> =A0 =A0 > =A0 =A0 <mailto:<a href=3D"mailto:xAP_developer-fullfe=
atured@xxxxxxx"
target=3D"_blank">xAP_developer-fullfeatured@yahoog=
roups.com</a><br>
> =A0 =A0 <mailto:<a href=3D"mailto:xAP_developer-fullfeatured@yahoog=
roups.com"
target=3D"_blank">xAP_developer-fullfeatured@xxxxxxx</a>=
>><br>
> =A0 =A0 ><br>
> =A0 =A0 ><br>
> =A0 =A0 ><br>
> =A0 =A0 ><br>
> =A0 =A0 ><br>
> =A0 =A0 ><br>
><br>
><br>
><br>
> =A0 =A0 ------------------------------------<br>
><br>
> =A0 =A0 Yahoo! Groups Links<br>
><br>
><br>
> =A0 =A0 =A0 =A0mailto:<a href=3D"mailto:xAP_developer-fullfeatured@yah=
oogroups.com"
target=3D"_blank">xAP_developer-fullfeatured@xxxxxxx<=
/a><br>
> =A0 =A0 <mailto:<a href=3D"mailto:xAP_developer-fullfeatured@yahoog=
roups.com"
target=3D"_blank">xAP_developer-fullfeatured@xxxxxxx</a>=
><br>
><br>
><br>
><br>
><br>
><br>
><br>
<br>
<br>
<br>
------------------------------------<br>
<br>
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|