p2psp team mailing list archive

[Ilshat Shakirov <im.shakirov@xxxxxxxxx>]

Hello,

Here is small status update (by the results of the this week):
http://shakirov-dev.blogspot.ru/2015/07/8th-week.html#more

Vicente, Juan, thanks for the responses.

did you try tools/create_a_team.sh?
>
Yes, I've tried it, but I faced with problems with Xterm. I've tried to
reinstall it, but it didn't help. I will try more.

---

Just one thing: when the DS technique is completed we'll send the public
> key under a X.509 certificate format. Ideally this certificate should be
> signed by a trusted certificate authority and contain information about the
> organization managing the splitter to offer some degree of trust.
>
It's ok. To be honest I've never do this before, so Ill google it.

Regarding of the experiments: ll try to perform it as you described.

So my tasks for 9th week:
1. Sending keys with X.509 format
2. Perform tests for the STrPe technique.

Also, I wanted to develop heuristic for the excluding malicious peers from
the team based on the all the team (not only trusted peers). Do you have
any ideas? I think about smth like: 'exclude peer if more than x% of the
team marked it as malicious'. Also, we can assign 'reputation' to each
peer, so some peers will have more influence on the decision of excluding
peer. What do you think?

Thanks! =)


2015-07-23 2:01 GMT+05:00 Juan Álvaro Muñoz Naranjo <juanalvaro83@xxxxxxxxx>
:

> Hi Ilshat,
>
> first of all thanks for your update, it was very interesting. Just one
> thing: when the DS technique is completed we'll send the public key under a
> X.509 certificate format. Ideally this certificate should be signed by a
> trusted certificate authority and contain information about the
> organization managing the splitter to offer some degree of trust. The
> certificate might even be distributed with the software, or be given by the
> web page if we were in a web player with WebRTC. Otherwise the attacker
> might send its own public key to the peers impersonating the splitter. But
> for now it is ok like that.
>
> Now, let's get to the point. How to run the experiments. Vicente already
> suggested the use of tools/create_a_team.sh in a previous message (thank
> you Vicente!). Also, Cristóbal suggests this:
> https://github.com/cristobalmedinalopez/p2psp-chunk-scheduling/blob/master/tools/run_experiment.sh
> These solutions are for experiments in one machine of course, which is
> enough for us. If you need more peers you should be able to combine several
> machines by running one script per machine. Of course, we're interested in
> seeing how peers' buffers are filled with chunks and not in video playback:
> as you can see, both scripts send the video signal to /dev/null.
>
> Which experiment to run? We propose the following: we're interested in
> average expulsion times for an attacker, and if all of them are expulsed
> after a given time. Also, the average percentage of gaps in the peers'
> buffers (so we can see if playback is possible in presence of attackers and
> after how long). I think you should measure time in terms of sending rounds
> (you know, one round would be the splitter sending one chunk to every
> member of the team).
>
> So, let's say that you have a team of 100 peers. From that team, a
> percentage of peers will be malicious: 1%, 10%, 25%, 50%. I imagine a plot
> in which the X axis is time (number of rounds) and in which we depict:
> number of remaining malicious peers in the team (because some of them will
> be expulsed) and average filling of peers' buffers. Ideally, as the number
> of remaining malicious peers decreases the filling of buffers should
> increase.
>
> Showing the number of complains from peers in the first technique would be
> also interesting.
>
> Another thing to measure would be the percentage of bandwidth used for
> real multimedia data (this is, how many bytes from the total are really
> used for transmitting the video). You can compare the baseline (no security
> measures, just plain video without malicious attackers) against both
> techniques.
>
> So, for running these experiments you'll need to decide which information
> you want to store from each peer (buffer filling percentage at each
> iteration, how many malicious peers at each iteration, how many bytes were
> sent and how many of them were used for video, how many complains arrived
> to the splitter in every iteration). Am I forgetting anything?
>
> My suggestion is run the experiment for the first technique and see how it
> goes. Make sure to run the experiment more than once, say 5 times, and then
> get the average of them all.
>
> Good work,
>
> Juan
>
> 2015-07-21 20:06 GMT+02:00 Vicente Gonzalez <
> vicente.gonzalez.ruiz@xxxxxxxxx>:
>
>> Hi Ilshat,
>>
>> did you try tools/create_a_team.sh?
>>
>> (I tested to run up to 100 peers in my 8HG Mac machine)
>>
>> Regards,
>> Vi.
>>
>>
>> On Sun, Jul 19, 2015 at 8:36 PM Ilshat Shakirov <im.shakirov@xxxxxxxxx>
>> wrote:
>>
>>> Hello!,
>>>
>>> Sorry for the long delay.
>>>
>>> Here is status update about CIS of rules project:
>>> http://shakirov-dev.blogspot.ru/2015/07/5-6-7-week.html
>>>
>>> Also, I need some help with testing a big (ie, 20 peers) p2psp-teams. I
>>> want solution that allows to reproduce testing experiments easily. So the
>>> commenting lines (to remove need in running vlc) is not suitable for this.
>>> I've wrote simple script which runs several peers (in one machine) and
>>> here is result
>>> <https://www.evernote.com/shard/s427/sh/0b070670-8de9-4a61-acec-562035cfc3ef/7403917d3ca736eea6d60da8ba23543b>.
>>> I think it's quite hard to understand smth in this (and reproduce). So,
>>> what is the best solution for testing p2psp-teams and gather some stats?
>>>
>>> Thanks!
>>>
>>> 2015-06-25 16:13 GMT+05:00 Vicente Gonzalez <
>>> vicente.gonzalez.ruiz@xxxxxxxxx>:
>>>
>>>>
>>>>
>>>> On Wed, Jun 24, 2015 at 5:48 PM L.G.Casado <leo@xxxxxx> wrote:
>>>>
>>>>>  Hi all,
>>>>>
>>>>> El mié, 24-06-2015 a las 16:44 +0500, Ilshat Shakirov escribió:
>>>>>
>>>>> Ok; Is there any option run peer without running a player? I'm going
>>>>> to run all peers in one local machine, is it right?
>>>>>
>>>>>
>>>>>
>>>> At this moment, the easiest way to test a lot of peers in one machine
>>>> is to connect to each peer a NetCat client [
>>>> http://netcat.sourceforge.net/]. It is not the most efficient
>>>> solution, but you should be able to run hundreds of peers in a 8GB machine.
>>>> However, is quite simple to avoid sending the stream in each peer. Just
>>>> comment (temporally) the code that feeds the player.
>>>>
>>>> Regards,
>>>> Vi.
>>>> --
>>>> --
>>>> Vicente González Ruiz
>>>> Depto de Informática
>>>> Escuela Técnica Superior de Ingeniería
>>>> Universidad de Almería
>>>>
>>>> Carretera Sacramento S/N
>>>> 04120, La Cañada de San Urbano
>>>> Almería, España
>>>>
>>>> e-mail: vruiz@xxxxxx
>>>> http://www.ual.es/~vruiz
>>>> tel: +34 950 015711
>>>> fax: +34 950 015486
>>>>
>>>
>>> --
>> --
>> Vicente González Ruiz
>> Depto de Informática
>> Escuela Técnica Superior de Ingeniería
>> Universidad de Almería
>>
>> Carretera Sacramento S/N
>> 04120, La Cañada de San Urbano
>> Almería, España
>>
>> e-mail: vruiz@xxxxxx
>> http://www.ual.es/~vruiz
>> tel: +34 950 015711
>> fax: +34 950 015486
>>
>
>