[Nice] Starting with libnice
Youness Alaoui
youness.alaoui at collabora.co.uk
Fri Dec 16 14:42:17 PST 2011
On 12/16/2011 06:41 AM, Tiago Sá wrote:
> Hi Youness,
>
> Sure! I will share the application when I succeed.
cool :)
> Before trying to pipe from a local socket I am simply testing reading from a
> file and sending that data to the other agent.
> I am using nice_agent_new_reliable and pseudo_tcp is opened:
> "(process:11881): libnice-DEBUG: Agent 0xb97de0: s1:1 pseudo Tcp socket Opened"
> Can I assume that Nice will manage the acknowledgments, sequencing and all that
> TCP stuff?
Yes, libnice will handle all of that, you still use the libnice API the same
way, *but* there is a small difference between a normal agent and a reliable
agent. I will explain it below.
>
> This is the function I use to slice and send the file:
>
> int send_file(char *filename){
> FILE *file = fopen(filename, "rb");
> char *file_chunk = malloc(CHUNK_SIZE);
>
> size_t nbytes = 0;
> int sent=0;
> while ( (nbytes = fread(file_chunk, sizeof(char), CHUNK_SIZE,file)) > 0)
> {
> int offset = 0;
> while (((sent =
> nice_agent_send(agent,stream_id,NICE_COMPONENT_TYPE_RTP,nbytes,fi
> le_chunk+offset)) > 0) || (sent == -1 && errno == EINTR) ) {
> if (sent > 0) {
> printf("SENT FILE: chunk size: %zu send result:
> %d \n",nbytes,sent);
> offset += sent;
> nbytes -= sent;
> }
> }
> }
> return 0;
> }
>
> And the callback to receive:
>
> void
> cb_nice_recv (NiceAgent * agent, guint stream_id, guint component_id,
> guint len, gchar * buf, gpointer user_data)
> {
> FILE *file_received=fopen("testFile-received.txt", "ab");
>
> if(file_received){
> int writen = fwrite(buf,sizeof(char),len,file_received);
> printf("RECEIVED FILE: buf size: %d , writen size: %d\n\n",len,writen);
> }
> else{ perror("ERROR OPENING FILE\n"); }
> }
>
> It sends some chunks and then starts to fail on send.
>
> Problably I should use the "reliable-transport-writable" signal, to wait before
> trying to send a new chunk, but then, the signal must be handled by a different
> callback, am I write? Or can I "wait" for the signal on the same send_file function?
The read callback is fine, although you should remember to fclose the file...
As for the sending, you're not waiting for it to be writable. I don't think that
'errno' has any meaning either in the world of libnice...
The way you should do it is to send data using a callback function that you hook
into the reliable-transport-writable signal. That signal will be sent when you
first connect (so you don't need to listen for state changes actually), and then
it will only be sent if the nice_agent_send returns less bytes than you tried to
send or if it returns -1.
Don't forget that if you call nice_agent_send, and it returns the right number
of bytes sent, then the writable signal will not be emitted.. the emission of
the signal is only enabled IF the last operation of the nice_agent_send was that
it couldn't send the full buffer you gave it..
So here's a quick pseudocode to illustrate how you should do it :
void
writable_cb (NiceAgent *agent, guint sid, guint cid, gpointer data)
{
FILE *file = data;
char *file_chunk = malloc(CHUNK_SIZE);
size_t nbytes = 0;
int sent=0;
while ( (nbytes = fread(file_chunk, sizeof(char), CHUNK_SIZE, file)) > 0)
{
int offset = 0;
sent = nice_agent_send(agent,stream_id, NICE_COMPONENT_TYPE_RTP,
nbytes,file_chunk);
if (sent < nbytes) {
/* If return value is -1 it means nothing was sent */
if (sent == -1)
sent = 0;
/* seek back to the last byte that was actually sent, so it gets
read on the next pass */
fseek (file, nbytes - seek, SEEK_CURRENT);
/* break and exit the function, wait for the next signal callback
to continue sending the rest of the data */
break;
}
}
}
main() {
FILE* fd = fopen("some_file.txt", "rb");
agent = nice_agent_reliable_new();
g_signal_connect(agent, "reliable-transport-writable", writable_cb, fd);
}
This should be enough to give you an idea on what needs to be done.
Hope it helps!
Youness.
>
> Thank you for the helpful information you are sharing.
>
> Cheers,
> Tiago Sá
>
>
> On Mon, Dec 12, 2011 at 11:39 PM, Youness Alaoui <youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>> wrote:
>
> On 12/12/2011 06:20 AM, Tiago Sá wrote:
> > Hi again Youness,
> Hi again Tiago,
>
> >
> > my application is progressing in small steps.
> > We chose to use XMPP for the communication. We are using libstrophe, it lacks
> > some documentation, but was enough for our needs.
> > We implemented a naif handshake, life the one you mentioned above, by
> exchanging
> > some xmpp message stanzas.
>
> Cool, you may want to look at the jingle XEP to see how candidates are being
> transferred in a VoIP call.
>
> >
> > This application will be part of a research project involving the grid,
> where we
> > need private hosts (called agents) to be able to communicate someway. We will
> > implement that (inter-agent) communication protocol later, right now we are
> > concerned with the NAT traversal thing, and it seems to be working fine :)
> >
> > Now, I would like to ask you a final question:
> > Right now we are able to send strings using "nice_agent_send". We would
> like to
> > establish a socket between the hosts and use other common primitives to
> code our
> > application.
> > Maybe the best possibility would be to create some kind of pipe from an
> > "external" application using local ports (something
> > like http://code.google.com/p/gnat/)
> > Or, in a simpler way, just pipe stdin/stdout from another app, slice that data
> > and send it using libnice send primitive?
> >
> > Have you ever tried something like this?
> I have not tried something like that, but it shouldn't be too hard in my
> opinion. You could just create a local daemon that connects to the XMPP server,
> and when it gets a new local connection, it sends candidates and acts as a proxy
> between the 127.0.0.1:12345 <http://127.0.0.1:12345> socket and the remote
> socket with the
> nice_agent_send and the recv callback.
> Would be nice if that code gets shared if you ever get to do it. But I don't see
> anything that would prevent it from working.
> Good luck!
> >
> > Thank you very much for your help.
> >
> > Cheers,
> > Tiago
> >
> >
> >
> >
> > On Mon, Nov 28, 2011 at 12:46 PM, Youness Alaoui
> <youness.alaoui at collabora.co.uk <mailto:youness.alaoui at collabora.co.uk>
> > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>>> wrote:
> >
> > On 11/23/2011 01:14 PM, Tiago Sá wrote:
> > > Hi Youness,
> > >
> > > thank you for your suggestions.
> > > You'r right, the STUN/TURN server I was using had a connection limit. I
> > > installed the turnserver.org <http://turnserver.org>
> <http://turnserver.org>
> > <http://turnserver.org> one in a public addressed
> > > machine.
> > > I also changed the way how I was writing the candidates, setting those
> > pointers
> > > to NULL.
> > > ICE seems to be working properly now! :)
> > Glad it worked :)
> >
> > >
> > > I have a question:
> > > According to the example in
> http://nice.freedesktop.org/libnice/NiceAgent.html
> > > we should be able to start sending messages after the signal
> new-selected-pair
> > > is fired. However, I tried it but no success:
> > > void
> > > cb_new_selected_pair (void)
> > > {
> > > printf ("cb_new_selected_pair\n");
> > > nice_agent_send(agent, stream_id, NICE_COMPONENT_TYPE_RTP,
> > strlen("Ola"),"Ola");
> > > }
> > >
> > > That first message is never received. However, after "a while" I try
> to send
> > > again and it works. Do I have to wait for the other agent to be ready to
> > receive?
> > Humm.. that might not have been entirely true.. technically if there is a
> > selected pair, then it should work, unless you are ready locally, but
> the remote
> > isn't ready to receive yet. technically you should wait for the state
> to go to
> > READY... and not care about the selected pair.. the docs might be
> wrong there,
> > but it's been a while and I'm not entirely sure of the use case that
> would make
> > it fail (but in every other project, we use the READY state as an
> indication
> > that we're ready to send).
> >
> > >
> > > Well, this is a checkpoint for me, but I must ask for another
> suggestion now.
> > > I need to improve the way how the communication between agents is made
> > > (exchanging candidates/credentials, initiating p2p connections, etc...)
> > > As I read in this
> > > thread
> http://lists.freedesktop.org/archives/nice/2010-August/000330.html
> > , you
> > > wrote:
> > > "well, the serialization, if I understand what you mean, is how you
> send the
> > > candidates to the other side, right ? In that case, that's not part
> of the ICE
> > > methodology.. you can 'serialize' the candidates/user/pass any way
> you want..
> > > one method is to put it in the SDP of a SIP invite. You can also
> send it as an
> > > XML using Jingle's XEP over an XMPP connection.. it really all
> depends on what
> > > protocol is being used to connect to the server (SIP, XMPP, custom,
> other...).
> > > I'll let you decide on the best way to do that."
> > Thanks for searching in the archives :)
> >
> > >
> > > After doing some research, I feel a bit scared. That is a completely
> new world
> > > for me. Could you please point the "simplest and most feasible"
> solution for
> > > this problem? Should I choose SIP or XMPP?
> > > libjingle, for example, presents a huge API...
> > > Do you know any simple client, possibly allowing me to connect to an
> existing
> > > infrastructure (such as Google Talk), I could use for this trivial
> information
> > > exchange?
> >
> > Humm.. yes, libjingle is a big pile of **** :) my suggestion is to
> never use it!
> > The real question here is what do you need libnice for? what will the
> clients be
> > ? if it's for a game or some custom application and that you can
> control the
> > server and the client, then you can setup something custom. If you
> want to have
> > a list of contacts in your application and the user can just select
> one and it
> > will know what to do, then using XMPP might be the best solution. It
> really all
> > depends on your needs and capabilities.. you can decide all about it,
> but here's
> > a simple example if you want :
> > client sending to server is : --->
> > client receiving from server is : <-----
> > Comments are preceded with #
> > ----> HELLO
> > <---- HELLO 12345 # Where 12345 would be a random id that gets
> assigned to you
> > ----> 54321 BEGIN ICE # first number being the 'random id' of the
> destination
> > ----> 54321 ICE-CREDENTIALS <the_username> <the_password>
> > ----> 54321 CANDIDATE 1 UDP 192.168.1.100 43132 host
> > ----> 54321 CANDIDATE 2 UDP 1.2.3.4 52133 srv-reflx
> > ----> 54321 ICE DONE # To say you're done, you can send it to the peer
> > <---- 54321 ICE REPLY
> > <---- 54321 ICE-CREDENTIALS foo bar # the remote's credentials
> > <---- 54321 CANDIDATE 1 UDP 192.168.1.200 54521 host
> > <---- 54321 CANDIDATE 2 UDP 1.2.4.1 9614 srv-reflx
> > <---- 54321 CANDIDATE 3 UDP 4.3.2.1 32957 <tel:4.3.2.1%2032957>
> <tel:4.3.2.1%2032957> relay-reflx
> > <---- 54321 ICE DONE
> > [...]
> > ----> 54321 ICE DESTROY
> >
> > And your server just maps sockets with those random ids, and relays
> the data
> > from one socket to another. And you parse the received input and build
> your
> > candidates...
> > So this is a very simple, but of course inefficient, you get a random id
> > everytime, it's hard to improve the protocol, etc... so using XMPP
> would be
> > better, but if you really don't need that much, then this might be the
> solution
> > you want.. like I said, it really depends on what you need it for.
> > As for XMPP, you can look at the 'wocky' library
> > (http://cgit.freedesktop.org/wocky/)
> >
> >
> > >
> > > Thank you for your help.
> > You're welcome :)
> >
> > >
> > > Regards,
> > > Tiago Sá
> > >
> > >
> > >
> > > On Thu, Nov 17, 2011 at 9:42 PM, Youness Alaoui
> > <youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>
> <mailto:youness.alaoui at collabora.co.uk <mailto:youness.alaoui at collabora.co.uk>>
> > > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>
> > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>>>> wrote:
> > >
> > > On 11/16/2011 08:30 PM, Tiago Sá wrote:
> > > > Hi again Youness,
> > > > thanks a lot for your help.
> > > > I believe I solved the problems you pointed before.
> > > > I am using a dumb method to exchange candidates. I write them to
> > file and
> > > > exchange them using a ftp server (I will improve it later).
> > > >
> > > > So, the way I run it is:
> > > > (HostA) ./client l
> > > > (HostB) ./client r
> > > > //local candidates are gathered and written to file
> > > > (HostA) put leftCands.bin on FTP and get rightCands.bin
> > > > (HostB) put rightCands.bin on FTP and get leftCands.bin
> > > > //read local credentials and write them on the remote host
> > > >
> > > > I am using a relay server, that should work as a last resort. But
> > during the
> > > > local candidate gathering, sometimes it gets a relayed candidate,
> > but most of
> > > > the times it doesn't. Can it be related with timeouts?
> > > It's possible the timeouts are affecting it, but I doubt it, usually
> > the RTT
> > > would be 200ms, but if you don't get a response from the relay
> or the stun
> > > server, it will retry 4 times until it times out after about 3
> seconds.
> > > It's possible though that the server has a limit on the number of
> > allocations
> > > you can create (probably 5) and if you are testing your app and it
> > creates 2
> > > allocations each time (one for each side), then it's possible the
> > server starts
> > > rejecting your allocation requests (each time you want to use
> TURN, it
> > will ask
> > > the server to allocate a port for you for that specific
> connection, so
> > you have
> > > the same settings but one port for each stream/component).
> > > If that's the case, maybe that's why it sometimes works (when the
> > allocation
> > > times out from the server). libnice should technically
> deallocate when the
> > > stream is destroyed, so maybe catch your Ctrl-C and do an unref
> on the
> > agent
> > > before returning from the main.
> > >
> > > >
> > > > Either way, it can never get a pair a establish a connection. :(
> > > > I don't have a clue why this happens..
> > >
> > > A log + wireshark dump might be helpful in this case. You can enable
> > logging
> > > with :
> > > export NICE_DEBUG=all
> > >
> > >
> > > >
> > > > Can you please have a look?
> > > The code looks sane enough.. apart from the obvious method of
> exchanging
> > > candidates which isn't "optimal". One thing I noticed though,
> you just
> > fwrite
> > > the whole structure, but note that there are pointers in the
> structure
> > that will
> > > be written as is to the file, and not their content. I'm thinking of
> > > username+password (but those should be NULL if you use the RFC5245
> > compatibility
> > > mode) but mostly the turn structure (which is just for local
> > candidates and
> > > wouldn't be used anyways for remote ones, but it's best to set it to
> > NULL to
> > > avoid possible crashes).
> > >
> > > >
> > > > Cheers,
> > > > Tiago
> > > >
> > > >
> > > > On Fri, Nov 4, 2011 at 2:03 PM, Youness Alaoui
> > > <youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>
> > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>>
> > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>
> <mailto:youness.alaoui at collabora.co.uk <mailto:youness.alaoui at collabora.co.uk>>>
> > > > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>
> > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>>
> > > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>
> > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>>>>> wrote:
> > > >
> > > > Hi again Tiago,
> > > >
> > > > For the remote candidates, you will need a third party
> server to
> > > exchange that
> > > > information, usually the candidates would be sent over SIP or
> > XMPP for
> > > example.
> > > > ICE cannot work if you don't have a third party server with
> > which you can
> > > > reliably exchange candidates. For testing purposes you
> could have it
> > > print the
> > > > candidates to stdout, and you could copy/paste that into stdin
> > of the
> > > other
> > > > instance and have it parse the input.. or you could hardcode a
> > port to
> > > connect
> > > > to and do the candidate exchange.. there's no easy way of
> doing that
> > > though.
> > > > You cannot hardcode the candidates because the port used
> will be
> > random
> > > > everytime, also, you will need to exchange the randomly
> generated
> > > > username/password (nice_agent_get_local_credentials +
> > > > nice_agent_set_remote_credentials) to make the connectivity
> > checks work.
> > > >
> > > > As for your example, here are a few comments :
> > > > 1 - you call the nice_agent_set_relay_info with stream_id
> being
> > > uninitialized,
> > > > you must call it *after* you do the nice_agent_add_stream...
> > > > 2 - you don't need those GValues, you can just do
> > > > g_object_set (G_OBJECT(agent),
> > > > "stun-server", "66.228.45.110",
> > > > "stun-server-port", 3478,
> > > > NULL);
> > > > 3 - You shouldn't set the remote credentials as the same
> as the
> > local ones
> > > > 4 - In your print_candidate_info, you may also want to
> print the
> > port
> > > used.
> > > >
> > > > I hope this helps, let me know if you have further questions.
> > > >
> > > > Youness.
> > > >
> > > >
> > > > On 11/03/2011 12:57 PM, Tiago Sá wrote:
> > > > > Hi Youness,
> > > > >
> > > > > I have been trying to create a simple application based
> on the
> > first
> > > link you
> > > > > pointed before.
> > > > > Thanks for the tips you gave me. I have a couple of
> questions
> > though, if
> > > > you can
> > > > > help me.
> > > > >
> > > > > I need to find a way to get the remote candidates passed
> from
> > a peer to
> > > > another.
> > > > > Can you point an easy way to do that?
> > > > > Could I hardcode the remote candidates list, for testing
> purposes?
> > > > >
> > > > > Right now, I only get two local candidates (HOST and
> > SERVER_REFLEXIVE).
> > > > > I am trying to use the numb TURN server, shouldn't I get
> a RELAYED
> > > > candidate too?
> > > > >
> > > > > I am attaching the code. Can you please have a look at the
> > code and
> > > check
> > > > where
> > > > > the error could be?
> > > > >
> > > > > Thanks for helping!
> > > > >
> > > > > Regards,
> > > > > Tiago Sá
> > > > >
> > > > >
> > > > > On Wed, Oct 19, 2011 at 10:53 PM, Youness Alaoui
> > > > <youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>
> > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>>
> > > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>
> > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>>>
> > > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>
> > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>>
> > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>
> <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>>>>
> > > > > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>
> > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>>
> > > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>
> > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>>>
> > > > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>
> > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>>
> > > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>
> > <mailto:youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>>>>>> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > Welcome to the world of libnice :)
> > > > > Yes, doing NAT traversal is far from being easy, the
> only
> > > solution is
> > > > pretty
> > > > > much to use the ICE specification and that's not easy to
> > > implement, so
> > > > that's
> > > > > why you'd need to use libnice.
> > > > >
> > > > > For an example, you can have a look at the unit
> tests, like
> > > > > tests/test-fullmode.c for example, although that
> does a lot of
> > > stuff.
> > > > You can
> > > > > see a quick example in the documentation for
> NiceAgent :
> > > > > http://nice.freedesktop.org/libnice/NiceAgent.html
> > > > >
> > > > > For smaller examples, you can look at the libnice
> mailing list
> > > > archives, some
> > > > > people posted their example code where they were having
> > > problems. For
> > > > example, a
> > > > > very simple example can be seen here :
> > > > >
> > http://lists.freedesktop.org/archives/nice/2011-January/000404.html
> > > > > But make sure to click on the "Next message" to read
> the whole
> > > thread
> > > > because
> > > > > that example had a bug that I explained how to fix
> in the
> > following
> > > > emails.
> > > > > Same for this thread :
> > > > >
> > http://lists.freedesktop.org/archives/nice/2011-October/000434.html
> > > > >
> > > > > I hope that helps,
> > > > > Youness.
> > > > >
> > > > > On 10/19/2011 09:58 AM, Tiago Sá wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > my name is Tiago Sá, I am a junior researcher from
> Portugal
> > > and this
> > > > is my
> > > > > first
> > > > > > mail to this list.
> > > > > > I have a NAT traversal problem to solve and I have
> been
> > > looking for
> > > > a solution
> > > > > > during the last weeks, which, as I found out, is
> not so
> > > trivial as I
> > > > > thought before.
> > > > > > As stated on the libnice homepage, libnice seems to be
> > what I am
> > > > looking for:
> > > > > >
> > > > > > "ICE is useful for applications that want to
> establish
> > > peer-to-peer
> > > > > UDP data
> > > > > > streams. It automates the process of
> traversing NATs and
> > > > provides security
> > > > > > against some attacks. It also allows
> applications to
> > > create reliable
> > > > > streams
> > > > > > using a TCP over UDP layer."
> > > > > >
> > > > > >
> > > > > > I have been looking for the provided documentation
> and I am
> > > feeling kind
> > > > > of lost.
> > > > > > Is there any example application or tutorial to
> get started?
> > > > > > Could you please share a basic application of this
> kind or
> > > point me a
> > > > > direction?
> > > > > >
> > > > > >
> > > > > > Thanks in advance for your help.
> > > > > >
> > > > > > Regards,
> > > > > > Tiago Sá
> > > > > >
> > > > > > --
> > > > > > Tiago Sá
> > > > > > Universidade do Minho, Braga - Portugal
> > > > > >
> > > > > > http://about.me/tiagosa/
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Nice mailing list
> > > > > > Nice at lists.freedesktop.org
> <mailto:Nice at lists.freedesktop.org>
> > <mailto:Nice at lists.freedesktop.org
> <mailto:Nice at lists.freedesktop.org>> <mailto:Nice at lists.freedesktop.org
> <mailto:Nice at lists.freedesktop.org>
> > <mailto:Nice at lists.freedesktop.org <mailto:Nice at lists.freedesktop.org>>>
> > > <mailto:Nice at lists.freedesktop.org
> <mailto:Nice at lists.freedesktop.org> <mailto:Nice at lists.freedesktop.org
> <mailto:Nice at lists.freedesktop.org>>
> > <mailto:Nice at lists.freedesktop.org <mailto:Nice at lists.freedesktop.org>
> <mailto:Nice at lists.freedesktop.org <mailto:Nice at lists.freedesktop.org>>>>
> > > > <mailto:Nice at lists.freedesktop.org
> <mailto:Nice at lists.freedesktop.org>
> > <mailto:Nice at lists.freedesktop.org
> <mailto:Nice at lists.freedesktop.org>> <mailto:Nice at lists.freedesktop.org
> <mailto:Nice at lists.freedesktop.org>
> > <mailto:Nice at lists.freedesktop.org <mailto:Nice at lists.freedesktop.org>>>
> > > <mailto:Nice at lists.freedesktop.org
> <mailto:Nice at lists.freedesktop.org> <mailto:Nice at lists.freedesktop.org
> <mailto:Nice at lists.freedesktop.org>>
> > <mailto:Nice at lists.freedesktop.org <mailto:Nice at lists.freedesktop.org>
> <mailto:Nice at lists.freedesktop.org <mailto:Nice at lists.freedesktop.org>>>>>
> > > > > > http://lists.freedesktop.org/mailman/listinfo/nice
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Nice mailing list
> > > > > Nice at lists.freedesktop.org
> <mailto:Nice at lists.freedesktop.org>
> > <mailto:Nice at lists.freedesktop.org
> <mailto:Nice at lists.freedesktop.org>> <mailto:Nice at lists.freedesktop.org
> <mailto:Nice at lists.freedesktop.org>
> > <mailto:Nice at lists.freedesktop.org <mailto:Nice at lists.freedesktop.org>>>
> > > <mailto:Nice at lists.freedesktop.org
> <mailto:Nice at lists.freedesktop.org> <mailto:Nice at lists.freedesktop.org
> <mailto:Nice at lists.freedesktop.org>>
> > <mailto:Nice at lists.freedesktop.org <mailto:Nice at lists.freedesktop.org>
> <mailto:Nice at lists.freedesktop.org <mailto:Nice at lists.freedesktop.org>>>>
> > > > <mailto:Nice at lists.freedesktop.org
> <mailto:Nice at lists.freedesktop.org>
> > <mailto:Nice at lists.freedesktop.org
> <mailto:Nice at lists.freedesktop.org>> <mailto:Nice at lists.freedesktop.org
> <mailto:Nice at lists.freedesktop.org>
> > <mailto:Nice at lists.freedesktop.org <mailto:Nice at lists.freedesktop.org>>>
> > > <mailto:Nice at lists.freedesktop.org
> <mailto:Nice at lists.freedesktop.org> <mailto:Nice at lists.freedesktop.org
> <mailto:Nice at lists.freedesktop.org>>
> > <mailto:Nice at lists.freedesktop.org <mailto:Nice at lists.freedesktop.org>
> <mailto:Nice at lists.freedesktop.org <mailto:Nice at lists.freedesktop.org>>>>>
> > > > > http://lists.freedesktop.org/mailman/listinfo/nice
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Tiago Sá
> > > > > Universidade do Minho, Braga - Portugal
> > > > > www.tiagosa.com <http://www.tiagosa.com>
> <http://www.tiagosa.com>
> > <http://www.tiagosa.com> <http://www.tiagosa.com>
> > > <http://www.tiagosa.com>
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Tiago Sá
> > > > Universidade do Minho, Braga - Portugal
> > > > www.tiagosa.com <http://www.tiagosa.com>
> <http://www.tiagosa.com> <http://www.tiagosa.com>
> > <http://www.tiagosa.com>
> > > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > Tiago Sá
> > > Universidade do Minho, Braga - Portugal
> > > www.tiagosa.com <http://www.tiagosa.com> <http://www.tiagosa.com>
> <http://www.tiagosa.com>
> > >
> >
> >
> >
> >
> >
> > --
> > Tiago Sá
> > Universidade do Minho, Braga - Portugal
> > www.tiagosa.com <http://www.tiagosa.com> <http://www.tiagosa.com>
> >
>
>
>
>
>
> --
> Tiago Sá
> Universidade do Minho, Braga - Portugal
> www.tiagosa.com <http://www.tiagosa.com>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/nice/attachments/20111216/3846f11f/attachment-0001.pgp>
More information about the nice
mailing list