uIP throughput and number of sockets

Hello,
I am researching using the uIP Stack. I realize that there is a limit
to the throughput because only 1 un-NAK'd packet is allowed to exist.
But I can't figure out if this is for a single open socket or for all
packets.

to clarify:

if I have 32 open sockets (Ports 1000..1031)
can I send data on each one after the other before I receive the ACK
from the first sent packet? Or would I send data on the first socket,
wait for the ACK then send the data on the next socket.

Thanks in advance
Mat

Start a New Thread

mathieuschneider schrieb:

> if I have 32 open sockets (Ports 1000..1031)
> can I send data on each one after the other before I receive the ACK
> from the first sent packet? Or would I send data on the first socket,
> wait for the ACK then send the data on the next socket.

1st: Check the source.
2nd: From the definition of TCP each socket has its own ACK. So I would
presume you might send on all sockets before receiving an ACK for the
first one.

But what do you want to achieve by this ? A higher throughput ? Maybe
you should skip TCP and use UDP ?!
--
42Bastian

Note: SPAM-only account, direct mail to bs42@...
Start a New Thread

The idea is not so silly really, but to improve throughput that way goes a
bit against the whole philosophy on uIP in the first place.
Providing you would have a remote app that can make sense of the
"fragments" on multiple sockets with all these sockets tied to the same
"app", AFAIK it should be possible in theory, but there are several flies
in the ointment.
First uIP uses a single buffer for both TX and RX, so it would be hard to
have complete transactions 'spread' over several sockets.
Second, while you can actively open (request) sockets from uIP to the
remote client, you can bang data as much as you like, uIP exploits the
"delayed ACK", which won't change the Round Trip Time.
In other words, say you set your polling (for TX) in uIP 10 times faster
(eg. every 50 mS instead of 500 mS), you will still have the same
throughput.
Once you start solving these issues in an elegant enough way, you'll end up
with a stack that won't resemble uIP much anymore.
But indeed, if you can sequentially send packets over say 32 sockets, then
the delay will be reduced, thus the throughput will increase.
(providing each socket sends data in its own timeslot to amortise the RTT)

HTH
B rgds
Kris

On Wed, 25 Feb 2009 20:08:06 -0000, "mathieuschneider"
wrote:
> Hello,
> I am researching using the uIP Stack. I realize that there is a limit
> to the throughput because only 1 un-NAK'd packet is allowed to exist.
> But I can't figure out if this is for a single open socket or for all
> packets.
>
> to clarify:
>
> if I have 32 open sockets (Ports 1000..1031)
> can I send data on each one after the other before I receive the ACK
> from the first sent packet? Or would I send data on the first socket,
> wait for the ACK then send the data on the next socket.
>
> Thanks in advance
> Mat
>
> Start a New Thread

Well said Kris.

Thank you very much for the effort and clarity in your response.

Mathieu

--- In A..., wrote:
>
> The idea is not so silly really, but to improve throughput that way
goes a
> bit against the whole philosophy on uIP in the first place.
> Providing you would have a remote app that can make sense of the
> "fragments" on multiple sockets with all these sockets tied to the same
> "app", AFAIK it should be possible in theory, but there are several
flies
> in the ointment.
> First uIP uses a single buffer for both TX and RX, so it would be
hard to
> have complete transactions 'spread' over several sockets.
> Second, while you can actively open (request) sockets from uIP to the
> remote client, you can bang data as much as you like, uIP exploits the
> "delayed ACK", which won't change the Round Trip Time.
> In other words, say you set your polling (for TX) in uIP 10 times faster
> (eg. every 50 mS instead of 500 mS), you will still have the same
> throughput.
> Once you start solving these issues in an elegant enough way, you'll
end up
> with a stack that won't resemble uIP much anymore.
> But indeed, if you can sequentially send packets over say 32
sockets, then
> the delay will be reduced, thus the throughput will increase.
> (providing each socket sends data in its own timeslot to amortise
the RTT)
>
> HTH
> B rgds
> Kris
>
> On Wed, 25 Feb 2009 20:08:06 -0000, "mathieuschneider"
> wrote:
> > Hello,
> > I am researching using the uIP Stack. I realize that there is a limit
> > to the throughput because only 1 un-NAK'd packet is allowed to exist.
> > But I can't figure out if this is for a single open socket or for all
> > packets.
> >
> > to clarify:
> >
> > if I have 32 open sockets (Ports 1000..1031)
> > can I send data on each one after the other before I receive the ACK
> > from the first sent packet? Or would I send data on the first socket,
> > wait for the ACK then send the data on the next socket.
> >
> > Thanks in advance
> > Mat
> >
> >
> >
> >
> >
> > Start a New Thread