Hi Guys, Attached is the chatlog of our dev. meeting today.
Joachim
luke - hi luke - doh typo Joachim - hi Joachim - :) luke - im just telling steven steven - hello steven - hmm, seems ok with me :) luke - sweet Joachim - hi steven steven - hi joachim :) luke - steven and I were chatting the other day about bandwidth flow control Joachim - cool luke - he has a new design thats non blocking steven - may I explain the design now? steven - so that we can have a review first luke - yeah Joachim - perhaps we should wait for the others steven - hmm, that's ok luke - i was gonna say go for it :) steven - :) luke - but looks like joachim is on the phone Joachim - ready now luke - we can go over it again if people want to know steven - Dom and Chris and 'rock on' John :) Joachim - or just send the chat log to the list :) luke - i got a feeling we will be talking about timescales and suck Joachim - haha, yeah luke - suck > such steven - yep steven - maybe miss the deadline... Joachim - as usual ;) steven - is it this weekend? Joachim - yep, next monday steven - hoho luke - :) steven - ok, let me start explaining luke - guys its open source, we will get there when its done Joachim - duke nukem forever ? Joachim - "when it's done" Joachim - lol luke - right floor to steven Joachim - okay, back on topic ;) steven - actually it's not so far though steven - just a problem if I am quite busy on daily work :) steven - ok, what I was thinking about is two fold steven - the receiving part and sending part steven - we need both parts BWC, right? luke - umm steven - let me explain the sending part first luke - well only sending really luke - the other is just monitoring isnt it steven - that is the broadcaster steven - well, I think the receiving part also needs the BWC steven - maybe I am wrong luke - client -> server steven - when a client is publishing to a server luke - ok, well explain steven - and if the server responds lazily steven - the client (fp) will begin to drop packets luke - the response being stream bytes read ? steven - no, not exactly steven - but that's part of it steven - AFAIK if the server doesn't respond in terms of TCP ack steven - the client will try to adjust the sending window automatically luke - ok, i guess that will happen if we set the receive buffer in mina luke - im worried the packets might just queue up in mina steven - ok, I haven't get a full picture of how to implement a BWC when receiving steven - so let's first talk about the sending part luke - personally i dont think we need to.. if the client can send it.. we should handle it luke - if there is a limit luke - say.. kbps then and they exceed it luke - then perhaps close the connection steven - yep, that's one solution luke - since the client can set the quality steven - or more politely steven - set the quality ourselves steven - by trigger an event luke - can we do that ? steven - a server-side event steven - let app to handle that luke - ok, Netsteam.Bandwidth.Hog steven - let app to handle it luke - just joking steven - oh, network congestion again luke - shall i turn off my camera steven - I saw your head, Luke :) luke - does ssh connection work for you steven steven - don't know luke - i mean if you have an ssh connection to a server outside china can is it faster going over a tunnel Joachim - there is a NetStream.Play.InsufficientBW event Joachim - maybe we can use that luke - sounds good. steven - cool steven - Luke: don't know if that works for me steven - and seems it's ok now luke - so upstream bwc can be the bucket idea then trigger that event after they go over steven - let me continue steven - the sending part has two types of modes steven - the pull mode steven - and the push mode steven - for the push mode, life is easy steven - we just drop packets when token is not available luke - yup steven - considering that all packets are live packets steven - as to pull mode steven - we need one scheduler John Grden - hey guys Joachim - hey john steven - and with the help of Token Distributor thread John Grden - long time no see! Joachim - yep steven - hi john steven - nice to see you John Grden - brb...getting aspirin John Grden - hey Steven! John Grden - nice to read you Joachim - so the scheduler thread would fetch the packets from the clients steven - let me explain it in detail luke - ive got a brown asprin :) steven - firstly steven - a thread reads and sends the first packet from a FileProvider steven - with Channel.write luke - guys lets turn off the cameras luke - its slowing down for steven John Grden - better? Joachim - /me stopped the cam luke - hmm. my freeze frame sucks :) John Grden - LOL luke - i told him to reconnect John Grden - is that working better for you now steven? John Grden - ah' luke - i think the packets were stacking up steven - hi Joachim - better now? steven - I am back steven - better now :) Joachim - cool luke - so.. Channel.write steven - yep, before this first Channel.write steven - the second packet should be saved on a scheduler steven - say the second packet's ts is 20ms steven - we put a job that will be triggered after 20ms Joachim - ah, therefore the new methods :) Joachim - okay steven - sorry, got something wrong here steven - it should be to put the job when the first packet has been sent steven - that's in messageSent's calling stack steven - so the while loop may be steven - messageSent->get next packet and schedule it steven - timeout/send packet luke - isnt there an overhead in scheduling each packet steven - ok, we can get an improvement here though Joachim - and you're limited to the resolution of the scheduler steven - but it can be derived from this solution luke - ok, carry on we can comment at the end steven - when the timeout occurs steven - the token may be unavailable at the time steven - the thread will call ITokenBucket.acquireTokenNonblock(amount, task) steven - this will return immediately steven - the second parameter is a task that will be triggered by the token distributor when the token is available luke - a token is just true or false ? steven - and the task will schedule the next packet accordingly steven - a token represents for one byte steven - the first param 'amount' is the number of bytes the thread requires steven - it will return false, when the token is not available luke - ok steven - so that's the solution I though of for VOD steven - here we need only two extra threads steven - one is the scheduler John Grden - what's VOD real quick? steven - and the other is the token distributor Joachim - video on demand John Grden - cool steven - the remaining threads are from mina steven - and the solution is nonblocking luke - ok, can i make some suggestions steven - of course :) luke - :) luke - i think we should not schedule every packet luke - i think the design is right apart from that part luke - the token thread adding to the bucket steven - ok, we may schedule every two? luke - i think we should have buffers in the token bucket luke - and only pause when the buffer is empty luke - so flow would work steven - well, I think the buffer may not locate in token bucket luke - stream starts.. you are given a buffer of 100 kb steven - maybe in the stream luke - yeah, well im kinda thinking you start with some extra credits so to speak :) luke - equal to the size of the buffer luke - but it could be in the stream i guess luke - anyway.. it would work like this luke - say buffer is 100 steven - a phone call, a min luke - we stream until the bucket is empty and the buffer is 0 luke - so write, written, write, written, write, written, write..... luke - at some point we run out of tokens and buffer.. luke - everything stops... luke - the bucket gradually fills up again luke - the second thread in the background monitors the bucket luke - once it reaches the buffer start size.. luke - it kicks off the streaming process again luke - depending on the size of the buffer luke - and the speed of the clients connection luke - the scheduler may come into play luke - every few seconds... or perhaps a couple of times a min Joachim - perhaps we should start filling the buffer when it's only X percent full Joachim - so it never runs completely empty luke - shall we say buffer and bucket are the same thing :) luke - its a little confusing having two terms Joachim - yeah :) luke - if we auto fill the bucket ( im sticking to this term ) steven - back luke - we are not controlling bandwidth steven - let me scroll over the comments first :) luke - if you consider buffer and bucket to be the same thing luke - and there is a start value and an max value luke - then the token thread would stop adding to the bucket once the max was reached luke - and the streaming would stop once the bucket was empty luke - and would start again when its reached the min value luke - am i making any sense Joachim - yes, everything clear now Joachim - thanks luke - what do you think steven ? steven - I am reading your comments :) steven - got it, one more comments steven - the buffer should filled according to the packets' ts steven - say we have a buffer size of 100kb steven - we'd better schedule the folloing 101th kb's packets according to its ts steven - how do you think of it luke - ok, umm so say.. current ts is 100 and the stream started 50s ago luke - then we schedule a 20s sleep if the buffer is set to 30s steven - VOD is a little bit special than Live luke - we can use seconds instead of kbps luke - or both steven - the delay time won't be taken into account luke - actually thats ture luke - the backgroud thread will keep checking to see if we have enough tokens to start up again steven - say a packet of 30s ts steven - it may be scheduled in 40s if there's a delay of 10s steven - that bg thread is actually the token distributor steven - that may executes every 10ms to distribute tokens to all Buckets luke - i think the is the bucket full enough to start again is not an expensive operation so we can do it say once every second or two luke - instead of scheduling diff length sleeps steven - ok, I understand your point luke luke - just have a list of sleeping buckets, then iterater over them checking if they are full enough to kick back into action steven - but I think that may waste bandwidth luke - the server or clients bandwidth steven - say a 30s VOD steven - we assume it's only 100kb steven - if we have buffer of 100kb steven - we will send it at once luke - yes.. it would stream a super speed luke - then play back from the clietns buffer steven - but the client may not play at much luke - hmm steven - maybe stop in the middle luke - well the app developer will have control over the buffer luke - its the same game as on the client side luke - if i set a big buffer im assuming the client will want to watch lots of the video luke - if i set it too small it may be jerky but, in theory more bw efficent steven - :) steven - cool steven - so that's the solution Joachim - great luke - ok great steven - any problem with the whole picture? luke - oh i have serials for the profilers luke - for all of us luke - i will send out after the meeting luke - no problem, can we add the min and max to the buckets Joachim - steven: sounds like a cool design luke - and allow app devs control steven - every bucket has a capacity steven - is that enough? luke - umm.. luke - i guess we can store the min size in the stream luke - its not really the buckets concern steven - why to worry about the min size? luke - umm luke - well luke - we dont want to start streaming again when the bucket has say 1 token in it luke - since we will end up stopping again luke - probably the next packet luke - we will end up with possibly using scheduler for every packet steven - well, that all depends on the comparison of the size of next packet and the tokens in the bucket luke - so having a min setting will allow us pause long enough steven - I think it should send packet when the token is available luke - chris watch out! Chris - sorry I'm late John - Hey Chris, turn off your vid luke - there is a ufo above your head steven - hi Chris :) John - that's cool ;) John - LOL steven - hoho, I saw it too steven - you are not late ,we just start early :) Chris - ahh Chris - that's what I thought Chris - I thought it was at 10 Chris - anyway luke - did we get times wrong ? Chris - could be me luke - an who cares we are all here now Chris - cool steven - except Dom Chris - well I unfortunately can't stay too long Joachim - hi chris Chris - have to go to a meeting luke - so lets say we are happy with the bwc, we can fine tune details by testing in real world Chris - hi Joachim John - sounds good to me ;) luke - great work steven Joachim - yes, well thought John - you all are friggin' genius's steven - I think I should rush to implement it steven - to catch up with the schedule :) John - we definatly should talk about the .5 release John - and how things are going luke - i've been rather bust on projects :( John - me tooo steven - me too :( John - man it's been crazy luke - actually havent been much use Joachim - i did some updates John - me neither luke - joachim has been holding ship Joachim - john, did you update the roadmap? John - yeah J and steven John - ;) Chris - yeah steven - yep John - I did Joachim - cool John - last time we talked steven - thanks Joachim John - http://www.osflash.org/red5/roadmap#0.5_spring_loaded_web_applications_release_datejune_26th_2006 John - we have it listed as June 26th John - 7 days from now luke - so, lets all say what we are interested in working on luke - what we want help on John - ok, you mean John - based on the 4 items John - listed in the roadmap for .5? steven - ok, the main part of stream API has been done John - ok steven - BWC is discussed just now Joachim - john: the new features are not on the roadmap luke - cool, im happy to help with bwc steven - and I will finish it ASAP John - no? Joachim - no ;) John - ok, can you send me? Joachim - sure luke - also i think i should put time into remoting and amf stuff John - and I'll update along with the other updats you asked for on Firday? steven - Joachim surely has got many new features done :) John - thank s j John - HA luke - joachim found some issues so I should look into it John - yes, he's been very busy Joachim - 1. remoting client support Joachim - for which i added asynchronous support yesterday Joachim - 2. persistence Joachim - 3. periodic events Joachim - 4. SO event handlers John - LOL John - I'm reading it in your email John - sorry John - now I'm putting 2 and 2 together John - got it Joachim - and the corresponding updates for the migration guide Chris - this is very cool Joachim - so ppl actually know how to use these things ;) Chris - yeah the documentation is going well joachim Joachim - thanks Chris - thanks for doing that steven - yep steven - great job John - done: John - http://www.osflash.org/red5/roadmap Joachim - cool John - I'll get the corresponding links for migrations out there now Chris - Security (using Acegi security system)? Chris - that's not done right? steven - no Chris - no one is working on it either Chris - AFAIK Joachim - yep luke - nobody has touched it Chris - still seems premature to do it too steven - move to later release? Chris - we did talk about a permission based system luke - along with the permissions stuff ? Chris - and perhaps this can tie into it Joachim - yes Chris - exactly luke - any time i get this week i should put to amf and streaming help i think luke - so lets bump it Chris - I think it's a good idea steven - cool luke Chris - plus it's not a feature that people are clammoring for John - ok John - I'll bump to .6? Chris - cool luke - joachim forgot to add the xml-rpc stuff is done steven - well, actually client session management is an important feature Chris - right Chris - that's part of the logging John - JOACHIM: I added it: Joachim - ah right John - http://www.osflash.org/red5#red5_help_and_information John - is this what you had in mind? John - xml-rpc John - how should I list that on the roadmap John - ? Joachim - john: looks good John - cool -and great work Joachim! Chris - Simple web based http log / debug console (XML/RPC based) Joachim - "initial support for statistics through xml-rpc and rtmp" Chris - or that luke - :) Joachim - now with the new application handlers, the same class can be used in the xml-rpc service and the rtmp handler Joachim - so you need to write the statistics functions once and can call them through either protocol steven - You've really done a great job Joachim Chris - very cool luke - yeah excellent, and we can apply one security system to both in 0.6 Chris - so sounds llike we can meet our deadline Chris - for 0.5 luke - ok, well thats to be seen steven - just lack of test... John - ok updated luke - i think we have a bit to do Chris - ok luke - streaming work, and lots of testing Chris - you want to list those items luke? luke - to get things back to where we were with 0.4 John - roadmap updated Chris - testing as in Unit testing Chris - or more general QA Chris - ? luke - at the moment we have people reporting issue with streaming luke - we need to have time for steven to complete luke - based on his schedule Chris - ok luke - and with help if he needs it steven - more general QA is preferred too luke - then after that we need QA luke - before the release Chris - ok Chris - sounds good luke - so i think, the release date may slip a little Chris - a week might be tight John - yeah I was just thinking John - maybe 2 weeks Chris - we can also let people know to test these things as they come out steven - it won't be tight if I work for it full-time Chris - haha John - lol Chris - can you though? steven - but... Joachim - :) Chris - that's what I thought... John - So it might sound more like 3 weeks luke - yeah, i think we need a week for testing and fixing any issues which remain after streaming work steven - many OT recently :( John - 1-2 to get to QA mode, then a week of QA? Chris - wow no kidding Joachim - yeah, this really needs to be tested John - agreed steven - really Chris - ok John - so, Chris - the people on the list ma be a good resource for tesing Chris - testing Chris - thoughts on that? luke - ok, steven if you want me to do anything send me an email John - June 3rd? steven - thanks luke steven - I will setup something basic John - that's 3 weeks includng this one steven - and all of us can improve John - +1? Joachim - luke: what about the refactoring of the rtmp messages? should i work on this? Chris - well John and I have to fond some time to finish the website luke - umm let me checking what i have John - yes, we sure do John - :)) Joachim - cool luke - i will do it today, im a little worried its out of sync with the current codebase Chris - let's talk this afternoon John luke - but you will see the idea at least luke - so, we have one new guy Joachim - okay, i will ask on gtalk if i don't understand ;) luke - :) cool luke - he is going through the code getting comfortable John - ok chris sounds good luke - i say we put him on a 0.6 thing Chris - yeah John - whos the new guy? Chris - and he can help test John - is it the one that just wrote us? luke - maybe permissions, or acegi (he said he was good at spring) luke - yeah Chris - marijan John - ah ok Chris - that's his name luke - i emailed him today, to say some to meeting John - I'll have to get him a login Chris - yeah Chris - do that' luke - but he had a meeting John - ok Chris - well I have a meeting too Chris - ;-) luke - im looking forward to scripting in next release Chris - so I should go John - yeah me too John - ;) John - ok, Chris Joachim - yeah, scripting would be great John - I'll chat with you later on bud Joachim - and a compiling classloader as well Chris - ok luke - i got the code sitting waiting :) Chris - haha Joachim - :) steven - cool John - \m/ Chris - Spark? Chris - mjust be luke - yeah, parts of it Chris - ok, I'm really going now Chris - see you guys John - d00d don't tease me steven - bye chris Joachim - cya Chris - thanks for the hard work John - cya luke - and i can take a bit of cocoon :) steven knows it steven - hehe steven - we are making a project on that steven - together with Red5 John - nice! steven - Red5+jetty+cocoon Joachim - cool John - wow very cool John - hey Joachim: how's your screensharing app coming along? Joachim - pretty good Joachim - i started porting everything to red5 John - you guys have any eta's on demos? Joachim - i will ask about it... Joachim - the migration was pretty smooth and the code is _much_ more readable than before luke - john: :) your red5 training coming up Joachim - but we need bwc for productive use :( steven - don't worry joachim luke - yup, its coming :) Joachim - :) thanks steven - it's coming soon John - yea trainging is coming up;) Joachim - john: you think you have time to hack together a little flash tester for the amf datatypes? John - I'm likely to hit you guys up for some things I should cover in that John - sure John - yeah, can you send me an email with what you specifically need? Joachim - yes luke - i wrote server side unit tests John - cool, would you prefer it being all in one FLA without class files? luke - but if my logic was wrong i will just validatye im wrong :) Joachim - the problem is that some things seem to work fine when using the red5 serializer and deserializer John - lol, you've met my wife I see Joachim - but not when using a flash client John - ah ok luke - yeah, probably my fault for relying on server side tests Joachim - but i will check out the tests Joachim - actually noone seemed to be warned of all the "undefined" that appeared in the trace of ofla_demo.swf :) John - ok, send me not only the datatypes to test, but what type of UI that will help you diagnose what's returned Joachim - yes, will do John - cool luke - has chris gone John - with Xray, it's pretty easy to inspect objects that are returned John - yeah chris is DOA John - lol MIA steven - may I go back to work? John - yes John - thank you steven! luke - :) did he manage to get the unit test thing working on a mac John - LOVE YOU! Joachim - sure :) thanks a lot John - I have no idea steven - bye everyone :) Joachim - cya luke - no, you must give up the day job and join the clut of red5 luke - doh.. not much of a cult if i call it a clut steven - hehe Joachim - day job at day, red5 at night :) luke - :) where does that leave the gf :) luke - morning i guess John - LOL clut Joachim - weekends :) John - ha no doubt John - I think Chris and I are going underground to make the Red.org site happen John - we'll be on nightshift for a while luke - well, its all gonna take off when we are ready luke - i read someplace adobe are working on drm Joachim - i recently had an idea to make migration of defining methods a bit easier luke - but they have issues with patents Joachim - :) luke - found that kinda funny John - haha that is funny luke - do you know they are close to getting ruby on rails working on java John - what's your idea J? Joachim - currently, you have to add "IConnection conn = Red5.getConnectionLocal()" to the start of your method Joachim - if you need to access the connection, client or scope Joachim - we could try to pass the connection implicitly to the method as first parameter Joachim - so the user could define either "int add(int a, int b)" Joachim - or "int add(IConnection conn, int a, int b)" luke - yup that would work Joachim - at first, red5 would try to lookup the method with the connection luke - in a scripting you wont need it as we have script global scopt Joachim - and if it doesn't exist, it would use the method without the connection Joachim - yes luke - sounds good to me, just some login in the service invoker Joachim - but for java, you would have less code ;) Joachim - yes, will be very easy to implement luke - go for it Joachim - and ppl have the same syntax as for fcs/fms luke - is the connection the first param ? luke - i thought there was a global client object luke - and no connection object Joachim - i think fcs doesn't differ between connection and client John - I think that sounds right J Joachim - but i don't know exactly luke - well sounds cool to me luke - the reason i didnt do it that way luke - is i thought well people may call services which were not designed for red5 luke - but i think having it as the first way with a fall back to how it is now sounds perfect Joachim - yeah that's why i want to support both methods luke - we may need a conditional flag for turning off the login in scripting luke - or perhaps we will have a ScriptServiceInvoker Joachim - yes, or if ppl want to disable it for speed reasons luke - one per scripting engine Joachim - yep, or one serviceinvoker that determines the engine to use based on the file extension Joachim - so in theory you could mix python and java for one application :) luke - man im itching to get to scripting :) esp ruby Joachim - me python luke - everyone has their pet :) Joachim - hehe :) luke - ok, cool im gonna head back to work. unless you wanted to cover something else ? John - nah, I think we're good John - but John - did we agree to July3rd? Joachim - no, i'm fine luke - yes John - ok, so Joachim - +1 John - 2weeks of dev, 1 week of QA luke - think so luke - +1 John - +\m/ luke - there done John - cool John - I'll update the wiki John - thanks guys! luke - we all have to pitch in on the QA John - I'll update you on the convo that Chris and I have about the website John - yeah John - will do luke - cool, as always you guys ROCK! Joachim - \m/ John - man, YOU GUYS ROCK John - ha John - ;) John - cya soon Joachim - yup, cya Joachim - i'll send the chatlog to the lists luke - bfn John - ok, great thanks! John - I'll get John - the remoting test back to you as soon as I can John - after you get me what you need Joachim - great John - cooll John - l8r
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Red5 mailing list [email protected] http://osflash.org/mailman/listinfo/red5_osflash.org
