Flowcontrol
omn...@mario.n-ten.de
The situation is as follows. I have a thread which reads a file and
send's it via ariba. Therefore a loop reading chunks of 4k data and
transfers it. In a fast network this works fine, but over slow links
the reading thread fills ariba's buffers very quickly which finally
crashes. So the reading thread must be paused when the buffers are
getting too full. Is there a distinct support for this case or do I
have to implement it myself? If so, how can I access the bufferstatus?
By the way, is there a possibility to access the underlaying tcp-ack
state, or do I have to implement application layer-acks to keep track
of the arrival of messages?
Sebastian Mies
Am 29.07.2011 20:55, schrieb omn...@mario.n-ten.de:
> Is there any support for flowcontrol in ariba?
> The situation is as follows. I have a thread which reads a file and
> send's it via ariba. Therefore a loop reading chunks of 4k data and
> transfers it. In a fast network this works fine, but over slow links
> the reading thread fills ariba's buffers very quickly which finally
> crashes. So the reading thread must be paused when the buffers are
> getting too full. Is there a distinct support for this case or do I
> have to implement it myself? If so, how can I access the bufferstatus?
Currently there is no support for flow control in ariba. The main
reason for this lack is, that flow control in heterogeneous networks
(concatenating several TCP connections with RFCOMM etc.) is complicated.
If you only use direct connections you can implement this yourself if
you'd like. However, I would suggest a workaround for that problem...
> By the way, is there a possibility to access the underlaying tcp-ack
> state, or do I have to implement application layer-acks to keep track
> of the arrival of messages?
... because you would have to implement application layer-acks. If you
implement application layer acks and measure the time between them, you
could also estimate how much data you can sent. This results in somekind
of simple application-layer flowcontrol. This may not be exhaust the
available bandwidth perfectly, but it will prevent the buffers from
overflow and work well heterogeneous networks.
In my opinion, this you will get this done more quickly than extending
the protlib-based and RFCOMM transport with flow control capabilities.
Best regards,
Sebastian Mies
--
Karlsruher Institut für Technologie (KIT)
Institut für Telematik
Sebastian Mies
Wissenschaftlicher Mitarbeiter
Zirkel 2
Gebäude 20.20
76131 Karlsruhe
Telefon: +49 721 608-46416
Fax: +49 721 608-46789
E-Mail: mi...@kit.edu
omn...@mario.n-ten.de
I worked some days on the flow control, but it seems harder than I
thought.
Main problems are, ACKing every packet results in too much upload and
slows down the transfer (on asymmetric links). I'm experementing with
cummulative acks now. On the other hand sending enough un-acked data
to utilize most of the available bandwith results in termination of
the connection with a LinkDown event.
I just found this comment in the ariba code:
seqnum_t sendMessage(const DataMessage& msg, const LinkID& lnk);
* Sends a message via an established link. If reliable transport was
* selected, the method returns a sequence number and a communication
event
* is triggered on message delivery or loss.
But there's no corresponding callback in the CommunicationListerner.
Is this functionality actually implemented? Because this would be very
handy especially for the flow control issue..
Best regards, Mario
Sebastian Mies
to make the long story short: there is no flow control ATM.
Also, no ACK when a message left the local TCP send queue.
The main reason for the LinkDown when sending lots of
data is that the signaling messages from the base communication
are delayed and the link runs into a timeout. This is because,
currently, all messages are multiplexed into one single TCP
stream with no scheduling applied.
To prevent this from happening, one possibility is to reduce
the data chunk size, so signal messages can get through
in-time. You may experiment with that.
Best regards
Sebastian
--