0

Using AllJoyn signals based session problems

asked 2014-05-12 18:16:14 -0700

europelee gravatar image

Hi, AllJoyn signals based session is different from busmethod, it is asyn, so if a sender send msg very fast, and recver recv msg with signalhandler very slowly, then may happen data buffer are filled full on bus or tcp layer, and sender how find the problem, could slow its send speed?

edit retag flag offensive close merge delete

1 answer

Sort by ยป oldest newest most voted
0

answered 2014-05-13 14:53:51 -0700

bspencer gravatar image

There is no way to detect when a signal is received on the other side in order to adjust transmission speed. However you can put in a time to life on a signal (Signal API call C++) to ensure that if a bottleneck occurs the outdated signals will be dropped on the floor and only newer ones processed.

As a sender of Signals it is important to understand the frequency that you actually need to send things to be a good citizen on the network. Sending hundreds of Signals every second will actually slow down a network not due to bandwidth, but to actual work that a router needs to do for the small transactions. If you require understanding of delivery speeds you can insert a timestamp when sent and then have the other side send a Signal if it starts to notice things are backing up. With AllJoyn being so flexibly it is easy for a developer to insert their own throttle mechanism.

Things get interesting when using Sessionless signals as they overwrite the previous signal. When using a Sessionless signals what happens is a temporary session will be established. As such each Sessionless signal causes a joinSession and leaveSession calls internally in AllJoyn. As such a Sessionless signal is inefficent for a constant stream of data and should never be used as such. They should be used for persistent broadcast of data (e.g. About Feature) or for less frequent publications of data (e.g. Notification service framework).

edit flag offensive delete publish link more

Comments

hi, thank you for your help. in fact, i need sending big data from sender to recver as fast as possible, recver can recv and do audio/video streaming play(i use gstreamer), before i use raw session, it is ok, but i don't like the solution, so i try sessionsignal, and i need consider the above problem, as general, in socket programing, i would let sender blocks on sending, or sender take the outdated data into a tmp buff or file then try sending again next time, but i dont know the way deal with processing the above problem by sessionsignal of alljoyn

europelee ( 2014-05-20 17:54:02 -0700 )edit

Sending a signal when you are in a session is reliable delivery. So you do not need to block and re-transmit. On the other side you will receive the data in the order the signals were sent, this is part of the platform. As far as adjusting speed you would want to do something where you have a timestamp and you have a syncrhonization that occurs in which you compute the latency and the speed at which you should be sending the signals to avoid flooding the network. You can look at the AllJoyn Audio Service Framework to see how it implements this: https://git.allseenalliance.org/cgit/multimedia/audio.git/tree/

bspencer ( 2014-05-21 12:06:48 -0700 )edit
Login/Signup to Answer

Question Tools

Follow
1 follower

Stats

Asked: 2014-05-12 18:16:14 -0700

Seen: 2,264 times

Last updated: May 13 '14