From: Travis Stratman <tstratman@emacinc.com>
To: Ben Greear <greearb@candelatech.com>
Cc: netdev@vger.kernel.org
Subject: Re: data received but not detected
Date: Tue, 17 Jun 2008 17:58:26 -0500 [thread overview]
Message-ID: <1213743506.5771.220.camel@localhost.localdomain> (raw)
In-Reply-To: <48583B37.5070708@candelatech.com>
On Tue, 2008-06-17 at 15:31 -0700, Ben Greear wrote:
> Travis Stratman wrote:
> > I am working on an application that uses a fairly simple UDP protocol to
> > send data between two embedded devices. I'm noticing an issue with an
> > initial test that was written where datagrams are received but not seen
> > by the recvfrom() call until more data arrives after it. As of right now
> > the test case does not implement any type of lost packet protection or
> > other flow control, which is what makes the issue so noticeable.
>
> UDP packets can be lost anywhere..including in the receive buffer
> after it has been received by the NIC.
>
> You probably just need to write your code smarter to use non-blocking
> IO and deal with packet loss.
Thanks Ben.
I understand that there is no guarantee of anything with UDP, but it
seems to me that if there is a packet in the buffer (it shows up after
another packet comes in behind it) the system should know about it,
right?
The code will eventually deal with packet loss / retransmission (it is
actually a customer's application, not my own). Development was only
stopped at this point because this behavior was discovered. However, if
the final application behaves in the same way that things are going now,
the application would need to timeout on read, request retransmission,
receive the original packet (that was just stuck in the buffer
somewhere) and the retransmitted packet and decide which to toss every
couple of seconds. This is a whole lot more retransmissions than I would
expect to see on a cross-over cable, especially from receiving and
processing only two small packets at one pass.
If this is what's required I will relay that to the customer or
implement some type of workaround to force a poll or flush. However, if
there is possibly a bug or race condition that is not getting handled
properly it would be better to try and find it.
Thanks,
Travis
>
> Thanks,
> Ben
>
next prev parent reply other threads:[~2008-06-17 22:59 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-17 22:08 data received but not detected Travis Stratman
2008-06-17 22:27 ` Stephen Hemminger
2008-06-17 22:40 ` Travis Stratman
2008-06-17 22:31 ` Ben Greear
2008-06-17 22:58 ` Travis Stratman [this message]
2008-06-17 23:45 ` Ben Greear
2008-06-19 22:53 ` Travis Stratman
2008-06-19 23:08 ` Ben Greear
2008-06-22 9:16 ` James Chapman
2008-07-07 21:56 ` Travis Stratman
2008-07-08 9:37 ` James Chapman
2008-07-15 20:46 ` Travis Stratman
2008-06-18 6:28 ` Evgeniy Polyakov
2008-06-19 23:10 ` Travis Stratman
[not found] ` <20080620060219.GA22784@2ka.mipt.ru>
2008-06-20 17:10 ` Travis Stratman
2008-06-20 17:25 ` Evgeniy Polyakov
2008-06-20 17:41 ` Travis Stratman
2008-06-20 17:54 ` Evgeniy Polyakov
2008-06-20 18:17 ` Travis Stratman
2008-06-20 18:23 ` Evgeniy Polyakov
2008-06-20 21:06 ` Travis Stratman
2008-06-21 7:12 ` Evgeniy Polyakov
2008-07-07 21:10 ` Travis Stratman
2008-07-07 21:25 ` Evgeniy Polyakov
2008-07-15 20:43 ` Travis Stratman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1213743506.5771.220.camel@localhost.localdomain \
--to=tstratman@emacinc.com \
--cc=greearb@candelatech.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).