Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Vicente González Ruiz
    @vicente-gonzalez-ruiz
    Hi @hehaichi. Bug solved :-)
    Rakshith G
    @grakshith
    @vicente-gonzalez-ruiz , good job!
    Rakshith G
    @grakshith
    @vicente-gonzalez-ruiz , we can wrap up with the synchronizer. The last commit contains code to change the streams. As of now, only MPEG-TS streams work. I have been thinking of extending this to other video formats. But with things in their current state, I dont think it is possible. The only way I see it possible is when we operate on raw video streams and not encoded streams. But encoding on the go will be really slow. Any other changes to be incorporated?
    Vicente González Ruiz
    @vicente-gonzalez-ruiz
    Thanks @hehaichi. Please, remind to me where is your code :-)
    Vicente González Ruiz
    @vicente-gonzalez-ruiz
    Regarding the video-formats.MPEG-TS should be the used one in most situations (except when we must avoid any kind of patent issues). However, now that the header is transmitted directly between the source and the peers, the synchronizer should work with any type of video stream (I cannot in a reason to oponie the opposite).
    And not, I think that you have done all the work we proposed :-)
    Rakshith G
    @grakshith
    Yes, but when we try to synchronize the peers, we lose the headers
    Vicente González Ruiz
    @vicente-gonzalez-ruiz
    Why? The the stream that flows from the splitter to the peers does not have any header at all.
    @hehaichi, please, I think that you could do a last thing ...
    Could you provide (in a bash script, for example), an usage example of the synchronizer (as self-contained as possible ... I mean, creating the source, etc. if neccesary)?
    Rakshith G
    @grakshith
    Yes, of course!
    Rakshith G
    @grakshith
    @vicente-gonzalez-ruiz , done!
    Vicente González Ruiz
    @vicente-gonzalez-ruiz
    Thanks, @hehaichi. Please, confirm whether the script is run_a_source.sh.
    Rakshith G
    @grakshith
    Configure run_a_source.sh manually and then execute run.sh
    Vicente González Ruiz
    @vicente-gonzalez-ruiz
    OK, a last question. In which machine (OS) do you usually run the code?
    Rakshith G
    @grakshith
    Linux (Ubuntu 15.10)
    Vicente González Ruiz
    @vicente-gonzalez-ruiz
    Cool. I'll try the scripts ASAP and feedback to you. Thanks again!
    Rakshith G
    @grakshith
    Thanks for your time @vicente-gonzalez-ruiz !
    Vicente González Ruiz
    @vicente-gonzalez-ruiz
    It's my pleasure :-)
    Vicente González Ruiz
    @vicente-gonzalez-ruiz
    @hehaichi, I have incorporated your code to the p2psp-console repo. I think that it works properly (the script p2psp-console/test/synchronizer/run.shworks), but left to test if the latency is reduced when two teams are used to feed a peer. Could you check that in the new repository all your code is where it should to be? Another request: could you remove the warnings that are got when the code of synchronizer.ccis compiled?
    (maybe, you don't see the warnings because the compiler version)
    [ 87%] Building CXX object CMakeFiles/synchronizer.dir/src/synchronizer.cc.o In file included from /home/vruiz/P2PSP/p2psp-console/src/synchronizer.cc:11:0: /home/vruiz/P2PSP/p2psp-console/src/synchronizer.h: In constructor ‘p2psp::Synchronizer::Synchronizer()’: /home/vruiz/P2PSP/p2psp-console/src/synchronizer.h:57:34: warning: ‘p2psp::Synchronizer::player_socket_’ will be initialized after [-Wreorder] boost::asio::ip::tcp::socket player_socket_; // Socket to send chunks to player ^~~~~~~~~~~~~~ /home/vruiz/P2PSP/p2psp-console/src/synchronizer.h:56:36: warning: ‘boost::asio::ip::tcp::acceptor p2psp::Synchronizer::acceptor_’ [-Wreorder] boost::asio::ip::tcp::acceptor acceptor_; // Acceptor used to listen to incoming connections. ^~~~~~~~~ /home/vruiz/P2PSP/p2psp-console/src/synchronizer.cc:14:5: warning: when initialized here [-Wreorder] Synchronizer::Synchronizer() ^~~~~~~~~~~~ /home/vruiz/P2PSP/p2psp-console/src/synchronizer.cc: In member function ‘void p2psp::Synchronizer::ConnectToPeers(std::__cxx11::string, int)’: /home/vruiz/P2PSP/p2psp-console/src/synchronizer.cc:128:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] if(id!=peer_id){ ~~^~~~~~~~~ /home/vruiz/P2PSP/p2psp-console/src/synchronizer.cc:107:16: warning: unused variable ‘bytes’ [-Wunused-variable] size_t bytes = boost::asio::read(peer_socket,boost::asio::buffer(message,1024)); ^~~~~ /home/vruiz/P2PSP/p2psp-console/src/synchronizer.cc: In member function ‘void p2psp::Synchronizer::ChangeStream()’: /home/vruiz/P2PSP/p2psp-console/src/synchronizer.cc:244:14: warning: operation on ‘((p2psp::Synchronizer*)this)->p2psp::Synchronizer::peer_id’ may be undefined [-Wsequence-point] peer_id=(++peer_id)%(peer_list->size()); ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [100%] Linking CXX executable ../bin/synchronizer [100%] Built target synchronizer
    Thanks!
    Rakshith G
    @grakshith
    @vicente-gonzalez-ruiz , I've generated a PR with the required changes
    Vicente González Ruiz
    @vicente-gonzalez-ruiz
    Loads of thanks :-)
    Rakshith G
    @grakshith
    @vicente-gonzalez-ruiz , instead of having to run the monitor peers separately, can't we have the first peer in a team to be automatically promoted to be a monitor? This would then solve this issue hehaichi/p2psp-experiments#1
    That would also solve the case when a peer in a team loses only odd chunks or only even chunks...
    Otherwise, we need the peers to join a team that already has a monitor
    Or we need to put them behind two splitters(which wouldn't solve the odd-even chunk loss case)
    Vicente González Ruiz
    @vicente-gonzalez-ruiz
    Hi @hehaichi. Sorry, I forget to comment your issue (now, there is some questions related to that, please, see GitHub).
    Regarding your proposal (having the first peer in a team to be automatically promoted to be a monitor), I think that this is what is happening in the current version of the protocol. So, please, could you elaborate some more regarding this race condition you mention in the issue? Thanks!
    Rakshith G
    @grakshith

    What I'm trying to say is that, if I want 2 peers in the same team, to use the synchronizer, I need to run one peer as a monitor and other as a normal peer. If I run ./peer for both the cases, it fails because I get this error /home/rakshith/Desktop/Github/core/src/core/peer_nts.cc:204: ERROR: this->peer_list_.size() != this->number_of_monitors_
    So, I need to have at least one monitor in my team, or else I have to pass the number of monitors as zero in the splitter arguments.
    If we don't have monitor, I think LRS won't work.

    So, is it not possible to dynamically create monitors in a P2PSP team?

    Vicente González Ruiz
    @vicente-gonzalez-ruiz
    Yes, @hehaichi, the monitors can be created dynamically, but this must be programmed. However, I have a new question. Which is the reason for connecting 2 peers of the same team to the same synchronizer? Usually, the 2 peers should belong to different teams (which transmit the same stream).
    Rakshith G
    @grakshith
    Remember the case you had mentioned when one peer loses only even chunks and the other loses only odd chunks. Synchronizer would help here
    Vicente González Ruiz
    @vicente-gonzalez-ruiz
    Yes, you are right (specially if I mentioned it :-)) Well, to allow monitor peers are incorporated at any moment (not at the beginning of the creation of the team), only a few number of modifications should have done. I'm thinking "on the fly", but I suppose that the monitor should send to the splitter a signaling message and the splitter label the monitor (now, all monitors are at the head of the list of peers, so the splitter could insert the monitors in the "head" of use a field/peer in the list to distinguish them -- I prefer the first option, anyway). Would you like to implement such improvements?
    Rakshith G
    @grakshith
    Yes! I'll start working on it...
    Vicente González Ruiz
    @vicente-gonzalez-ruiz
    Thanks! This functionality is very interesting :-)
    Rakshith G
    @grakshith
    @vicente-gonzalez-ruiz , I am a bit confused. How exactly is an incoming peer handled? As I see its the SplitterNTS class that's handling peer arrivals as of now. Based on the signalling message of the monitor, the splitter should increase the number of monitors of the team. Am i correct?
    Vicente González Ruiz
    @vicente-gonzalez-ruiz
    Yes, when NTS is enabled, peer arrivals are controlled by this layer. Otherwise, DBS. The number of monitors should be decided by the administrator(s) of the team, depending on the available resources (each monitor need to run in a different host) and the effort that the adminitrator(s) want to put in computing the predicted source ports for those peers that are running behind NATs. Hope this info helps!, @hehaichi.
    jellysheep
    @jellysheep
    Hi @hehaichi, @vicente-gonzalez-ruiz asked me to answer your question, as I implemented the NTS protocol.
    You're right, upon each newly incorporated monitor, the number of monitors should be increased (naturally). Also, all NTS algorithms/codes depend on the fact that the monitors are at the beginning of the splitter's peer list. So this should be ensured when adding new monitors. Also, the new monitors have to be announced to all peers like a new regular peer (though this might not require a change in the code).
    Besides that, incorporating monitors after peers could probably just work fine, let's just see what happens. :)
    jellysheep
    @jellysheep
    Or does the synchronizer (?) depend on the peer list order, with the monitors at the middle/end?
    Rakshith G
    @grakshith
    @vicente-gonzalez-ruiz , @jellysheep. Thanks a lot for the info!
    Rakshith G
    @grakshith
    @jellysheep, currently the synchronizer doesn't depend on the peer list order as it is meant to be used with peers from multiple teams transmitting the same video. However, one interesting issue that could arise in a team can be solved using synchronizer. That issue precisely is when one peer loses only odd chunks and another peer loses only even chunks. In this case, the synchronizer could be of use. To do that, we need to overcome this hehaichi/p2psp-experiments#1 . Thus we need dynamic creation of monitors. (What I'm trying to say is that, a peer run with ./peer should act as a monitor if its the only member in the team)
    Rakshith G
    @grakshith
    @vicente-gonzalez-ruiz , I have been quite busy lately (course projects). Will start working on this soon.
    Vicente González Ruiz
    @vicente-gonzalez-ruiz
    It's fine. Anyway, thanks for keeping me informed!
    Rakshith G
    @grakshith
    @vicente-gonzalez-ruiz , I apologize for the delay! I am done with the exams now. I hope to cover substantial stuff in these vacations.
    Rakshith G
    @grakshith
    @vicente-gonzalez-ruiz, hehaichi/p2psp@4b70f35, take a look at the commit. I've tried to implement the dynamic creation of monitors for the EMS layer. I've tested it too. It works fine. Only one thing, we need to decrement the number_of_monitors counter when a monitor peer dies. I will do it in the next commit.
    Vicente González Ruiz
    @vicente-gonzalez-ruiz
    Thanks @hehaichi .
    Rakshith G
    @grakshith
    @vicente-gonzalez-ruiz , how to compile p2psp-console to use NTS?
    Rakshith G
    @grakshith
    @vicente-gonzalez-ruiz @cristobalmedinalopez, PR raised.
    Cristóbal Medina López
    @cristobalmedinalopez
    Hi there! Thanks for the PR. We will take a look at it as soon as possible.
    BTW, sorry for the delay, we had a lot of work these days.