Nsis_Imp July 2006

nsis_imp@informatik.uni-goettingen.de

11 participants
15 discussions

RE: [Nsis_imp] Implementation
by Christian Dickmann 30 Aug '06

30 Aug '06

Hi, > To use NSIS implementation I must use a real scenario (I mean > that I must run the NSIS damon as much computers as are the > nodes that are in my topology) or I can simulate it? The > use of the alias interfaces are supported by the implementation? > I can run, to simulate a scenario, different NSIS damons (based > on different nsis.conf) on the same machine? No, this is not possible. Personally, I use QEMU to emulate virtual PCs on my laptop. These virtual PCs can be connected to form an virtual network. This way, you can model your topology and run it as if you really had this number of machines. If you wish, I can provide you with a QEMU harddisk image, which you only need to copy as many times as you want to have virtual machines. In addition I have a sample starting script showing how to build the virtual network. Interested? > Moreover I would to know if there are new versions of the NSIS > implementation that interact with Mobile IP and that I can use. Not to my knowledge. Christian Dickmann

5 5

RE: [Nsis_imp] stateless GIST for RMD - howto
by Christian Dickmann 31 Jul '06

31 Jul '06

Hi, > * operate in unreliable mode. This can be satisfied > > by passing this requirement from the QoS-NSLP > layer to the GIST layer via the API > transfer-attributes. > > Okay, no problem here, I can set the Sendmsg() flag > fine. Correct. > * do not create a message association state. This > requirement can be satisfied by a local policy, > e.g., the QNE is configured to do not > create a message association state I am not sure here. The message association state needs to be created and maintained if, and only if, you want to have a message association (e.g. TCP) between the peers. If you choose the unreliable transport (i.e. UDP), which is the datagram mode (D-Mode), then there is no message associate and therefore no state (well, in fact, we have a minimal state too). On the other hand, if you want to have reliable transport (e.g. TCP), then you WANT a message association and therefore GIST NEEDS to maintain a message association state. Thus, I am not sure, what the authors mean here. If you do not know either, can you tell me the section of the draft where this is written? > * do not create any NTLP routing state. This can be > satisfied by passing this requirement from the > QoS-NSLP layer to the GIST layer via the API. Well, this is correct. At least in theory. The GIST specification lists this, but we have not yet implemented the stateless mode. Christian Dickmann

1 0

stateless GIST for RMD - howto
by pfer 31 Jul '06

31 Jul '06

Hello! First, thank you for all your help you've provided so far, they've proven most helpful. I would like to test my RMD-QoS-NSLP, but I might not be aware of all the GIST related topics I would need. The relevant RMD draft says: /RMD intra-domain node's GIST requirements/ RMD-QOSM MUST require the intra-domain GIST functionality available in these nodes to operate in the datagram mode, i.e., require GIST to: * operate in unreliable mode. This can be satisfied by passing this requirement from the QoS-NSLP layer to the GIST layer via the API transfer-attributes. Okay, no problem here, I can set the Sendmsg() flag fine. * do not create a message association state. This requirement can be satisfied by a local policy, e.g., the QNE is configured to do not create a message association state * do not create any NTLP routing state. This can be satisfied by passing this requirement from the QoS-NSLP layer to the GIST layer via the API. I'm not sure aboout this last two points, where to give these hints to GIST. An API call? Config file? Thanks in advance, Ferenc Pintér __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

NSLP API: waitForSignal crashes for stdin
by Gotthard, Petr 31 Jul '06

31 Jul '06

Hello, we've just identified a bug in NSLP API: The NslpApi::removeSocket() sets socket->sock = 0, what causes NslpApi::waitForSignal() to free the socket after callback processing. Problem is that 0 identifies a valid socket (stdin). Therefore, if stdin is inserted to the list, the NslpApi::waitForSignal() crashes or ends in an endless loop after first event. [The sockPtr->sock is stdin (=0), so it's freed in NslpApi::waitForSignal() after first event. As the NslpApi::removeSocket() has not been called, the (already freed) socket is never removed from the list, so the while cycle never finishes.] The following patch should fix the problem. diff -Nru nsis-0.4.1-dev/nslp/nslp_api/NslpApi.cpp nsis-0.4.1-new/nslp/nslp_api/NslpApi.cpp --- nsis-0.4.1-dev/nslp/nslp_api/NslpApi.cpp 2006-05-21 03:08:56.000000000 +0200 +++ nsis-0.4.1-new/nslp/nslp_api/NslpApi.cpp 2006-07-31 18:36:44.196586000 +0200 @@ -197,7 +197,7 @@ if (FD_ISSET(sockPtr->sock, &rfds)) { sockPtr->callback->SocketEvent(sockPtr->sock, sockPtr->data); - if (sockPtr->sock == 0) { + if (sockPtr->sock == -1) { delete sockPtr; sockIter = socketList->begin(); continue; @@ -243,7 +243,7 @@ if ((*sockIter)->sock == sock) { nslpapi_socket_t *socket = *sockIter; socketList->remove(socket); - socket->sock = 0; + socket->sock = -1; break; } } Could you please apply this patch to your development tree? thanx a lot Petr Gotthard

1 0

RE: [Nsis_imp] NSLP API: waitForSignal crashes for stdin
by Christian Dickmann 31 Jul '06

31 Jul '06

Hi, Thank you for this bug report and patch. We will apply it to our development tree immediately. Christian Dickmann ________________________________ From: nsis_imp-bounces(a)informatik.uni-goettingen.de [mailto:nsis_imp-bounces@informatik.uni-goettingen.de] On Behalf Of Gotthard, Petr Sent: Monday, July 31, 2006 7:00 PM To: nsis_imp(a)informatik.uni-goettingen.de Subject: [Nsis_imp] NSLP API: waitForSignal crashes for stdin Hello, we've just identified a bug in NSLP API: The NslpApi::removeSocket() sets socket->sock = 0, what causes NslpApi::waitForSignal() to free the socket after callback processing. Problem is that 0 identifies a valid socket (stdin). Therefore, if stdin is inserted to the list, the NslpApi::waitForSignal() crashes or ends in an endless loop after first event. [The sockPtr->sock is stdin (=0), so it's freed in NslpApi::waitForSignal() after first event. As the NslpApi::removeSocket() has not been called, the (already freed) socket is never removed from the list, so the while cycle never finishes.] The following patch should fix the problem. diff -Nru nsis-0.4.1-dev/nslp/nslp_api/NslpApi.cpp nsis-0.4.1-new/nslp/nslp_api/NslpApi.cpp --- nsis-0.4.1-dev/nslp/nslp_api/NslpApi.cpp 2006-05-21 03:08:56.000000000 +0200 +++ nsis-0.4.1-new/nslp/nslp_api/NslpApi.cpp 2006-07-31 18:36:44.196586000 +0200 @@ -197,7 +197,7 @@ if (FD_ISSET(sockPtr->sock, &rfds)) { sockPtr->callback->SocketEvent(sockPtr->sock, sockPtr->data); - if (sockPtr->sock == 0) { + if (sockPtr->sock == -1) { delete sockPtr; sockIter = socketList->begin(); continue; @@ -243,7 +243,7 @@ if ((*sockIter)->sock == sock) { nslpapi_socket_t *socket = *sockIter; socketList->remove(socket); - socket->sock = 0; + socket->sock = -1; break; } } Could you please apply this patch to your development tree? thanx a lot Petr Gotthard

1 0

RE: [Nsis_imp] Possible big/little endian considerations
by Christian Dickmann 29 Jul '06

29 Jul '06

Hi, Thanks for pointing this out. I guess our code for the A- and B-Flag of standard object header is also not big endian compatible right now. The issue will be fixed in the next version. Christian Dickmann > -----Original Message----- > From: nsis_imp-bounces(a)informatik.uni-goettingen.de [mailto:nsis_imp- > bounces(a)informatik.uni-goettingen.de] On Behalf Of Stephane Ouellette > (QB/EMC) > Sent: Friday, July 28, 2006 9:45 PM > To: nsis_imp(a)informatik.uni-goettingen.de > Subject: [Nsis_imp] Possible big/little endian considerations > > Folks, > > I've started to look at the code (v0.4.0) and found what might be a > possible issue regarding big/little endian encoding. > > In the file gist/message/headers.h is a definition of GIST's common > header: > > struct common_header_t { > unsigned char version : 8; > unsigned char hops : 8; > unsigned short length : 16; > unsigned short sappid : 16; > unsigned char type : 8; > unsigned char resrvd : 5; > unsigned char e : 1; > unsigned char r : 1; > unsigned char s : 1; > }; > > > To me, this is OK for a little endian machine. Don't we need macros to > distinguish between big/little endian architectures ? > > > struct common_header_t { > unsigned char version : 8; > unsigned char hops : 8; > unsigned short length : 16; > unsigned short sappid : 16; > unsigned char type : 8; > #ifdef LITTLE_ENDIAN_CPU > unsigned char resrvd : 5; > unsigned char e : 1; > unsigned char r : 1; > unsigned char s : 1; > #else /* BIG_ENDIAN_CPU */ > unsigned char s : 1; > unsigned char r : 1; > unsigned char e : 1; > unsigned char resrvd : 5; > #endif > }; > > > Regards, > > Stephane Ouellette. > _______________________________________________ > Nsis_Imp mailing list > Nsis_Imp(a)informatik.uni-goettingen.de > https://user.informatik.uni-goettingen.de/mailman/listinfo/nsis_imp

1 0

Possible big/little endian considerations
by Stephane Ouellette (QB/EMC) 28 Jul '06

28 Jul '06

Folks, I've started to look at the code (v0.4.0) and found what might be a possible issue regarding big/little endian encoding. In the file gist/message/headers.h is a definition of GIST's common header: struct common_header_t { unsigned char version : 8; unsigned char hops : 8; unsigned short length : 16; unsigned short sappid : 16; unsigned char type : 8; unsigned char resrvd : 5; unsigned char e : 1; unsigned char r : 1; unsigned char s : 1; }; To me, this is OK for a little endian machine. Don't we need macros to distinguish between big/little endian architectures ? struct common_header_t { unsigned char version : 8; unsigned char hops : 8; unsigned short length : 16; unsigned short sappid : 16; unsigned char type : 8; #ifdef LITTLE_ENDIAN_CPU unsigned char resrvd : 5; unsigned char e : 1; unsigned char r : 1; unsigned char s : 1; #else /* BIG_ENDIAN_CPU */ unsigned char s : 1; unsigned char r : 1; unsigned char e : 1; unsigned char resrvd : 5; #endif }; Regards, Stephane Ouellette.

1 0

Implementation
by Elena Scialpi - Unile 27 Jul '06

27 Jul '06

Hi all, I would want to use NSIS implementation in order to add to it the Semi-Proactive procedure (http://www.ietf.org/internet-drafts/draft-tommasi-nsis-semipro-00.txt). I have some questions... To use NSIS implementation I must use a real scenario (I mean that I must run the NSIS damon as much computers as are the nodes that are in my topology) or I can simulate it? The use of the alias interfaces are supported by the implementation? I can run, to simulate a scenario, different NSIS damons (based on different nsis.conf) on the same machine? Moreover I would to know if there are new versions of the NSIS implementation that interact with Mobile IP and that I can use. Thanks in advance, best regards, Elena ------------ LIIS Laboratorio per l'Internetworking e l'Interoperabilita' tra i Sistemi http://liis.unile.it http://www.campusdelsalento.it Office: (+39) 0832-297310 c/o Palazzo di Ingegneria Via per Monteroni I-73100 Lecce LE, Italy

1 0

RE: [Nsis_imp] qos-nslp local repair bug - is my GIST setupincorrectly?
by Christian Dickmann 26 Jul '06

26 Jul '06

Hi, > But you might be right, since change in the kernel > routing table might happen in A, before the whole > A-B-C route is ready. I will try doing the > local-repair after eg. 5 sec has passed. I haven't > thought of this. > > Ethereal is another good point, I should have tested > it more before sending this to the list. OK, no problem. 5 seconds waiting sounds like a good idea to try. > Also, is there a config file to make GIST send its > QUERY-s faster? It is not yet in the config file. You should try to start GIST with "-timer <value>", where <value> is the number of milliseconds between refreshes. 30000 is the default. > PS: > > Sorry, but I'm quite limited on Skype: > no net at home, and I do not have that fired up at > the lab, maybe I set it up at later date. No problem, was just an idea to speed up helping you :) > with GIST debug mode 2: > from A's sendmsg call to A's final recvmessage, > it took about 1.2 sec! > > with GIST no debug: > it took about 0.2 sec > > from these times, GIST takes about 90% > (though I heard call setups last long, > 1.2 sec on this 3 node wired setup made me jump) Wow, thats long. 0.2 seems fine. There are some portions of code which are only executed in debug mode, but this does not explain 1 additional second. Did you run GIST over SSH or something like this? Then the delay could be caused by this. Christian Dickmann

1 0

RE: [Nsis_imp] qos-nslp local repair bug - is my GIST set upincorrectly?
by pfer 26 Jul '06

26 Jul '06

Hi, sorry for not being clear: -all 3 nodes are connected and running Quagga/ospfd and your gist ver.3 initially -initially B is not on the A->C path (ospf cost is greater for A-B-C route) -I use the QoS-NSLP code I wrote on all nodes But you might be right, since change in the kernel routing table might happen in A, before the whole A-B-C route is ready. I will try doing the local-repair after eg. 5 sec has passed. I haven't thought of this. Ethereal is another good point, I should have tested it more before sending this to the list. Also, is there a config file to make GIST send its QUERY-s faster? PS: Sorry, but I'm quite limited on Skype: no net at home, and I do not have that fired up at the lab, maybe I set it up at later date. Interestingly enough, when earlier today I tested my QoS-NSLP's basic reservation like this: A--B--C init A: reserve(rii) -> B B: reserve(rii) -> C C: response(rii) -> B B: response(rii) -> A done with GIST debug mode 2: from A's sendmsg call to A's final recvmessage, it took about 1.2 sec! with GIST no debug: it took about 0.2 sec from these times, GIST takes about 90% (though I heard call setups last long, 1.2 sec on this 3 node wired setup made me jump) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Nsis_Imp July 2006