Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.188]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mBJIdoTV029495 for ; Fri, 19 Dec 2008 10:39:50 -0800 Received: by rn-out-0910.google.com with SMTP id j36so1142655rne.6 for ; Fri, 19 Dec 2008 10:06:41 -0800 (PST) Received: by 10.101.1.16 with SMTP id d16mr2398162ani.66.1229710001458; Fri, 19 Dec 2008 10:06:41 -0800 (PST) Received: by 10.100.197.17 with HTTP; Fri, 19 Dec 2008 10:06:41 -0800 (PST) Message-ID: <59e8babf0812191006x759e8f8fldeae3829d0d8e17a@mail.gmail.com> Date: Fri, 19 Dec 2008 10:06:41 -0800 From: "Michael Demmer" Sender: demmer@gmail.com To: "Andy Scott" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_29302_3720388.1229710001453" References: <494BA456.2040506@bbn.com> X-Google-Sender-Auth: 063a845739b6c19a Cc: dtn-users Subject: Re: [dtn-users] Windows Build - Status Update X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2008 18:39:51 -0000 ------=_Part_29302_3720388.1229710001453 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline > The coding standards are what's in the code -- I don't know of a > separate document. Actually there's a CONTRIBUTING file in the DTN2 source repository that lays out the coding conventions. That should probably be copied back to the oasys directory as well. Also the part that names me as the maintainer of the software should also probably be updated :) re:apache branch - fair enough I will give this a go. If this offers a > more portable approach to getting the exisintg code running on Win32 > then that is good. I have come to the realisation that the current > code in the repository is likely not a good base at all; it looks to > be far too fixed to the capabilities of non-Win32 platforms. And it is > likely that a new implementation specifically for Win32 would likely > be the best way forward. But I really do not like giving up easily > which is why I completed the curent patch. That's the reason I went down the apr-port route -- to get rid of the specific UNIX-isms from the code and instead program to the apr abstractions, and thereby make it easier for someone (like you) to go through the next step of getting things working on Win32 native. So a further two questions, if I may, about development of the code: > > 1. Is there a roadmap detailing supported platforms, bug fixes etc? Not really. > 2. Is there any more information regarding the Apache "port" > available? (I did a quick search of the main site using the search but > nothing - am looking through the mail archives now) Not really :) My intent was to complete the port and then merge those changes back into the mainline. Unfortunately I ran out of time in grad school and never finished the project, and now I'm onto other pursuits. >From what I remember of the status, I did get things most of the way there, including rewriting all the networking and file abstractions in oasys/io to use the apr wrappers, and I went through and updated at least the base DTN2 functionality to work with that. I also added a whole new mechanism for block caching of bundle payload data that makes things run much faster (since bundle data can be sent from memory without requiring it to be serialized to / from the disk). There were certainly some things still unfinished, and I never even attempted building on Win32, but I agree strongly with Chris that going the apr-port route would be a much better approach than trying to maintain Win32 compatibility with the existing tip of the tree. -m ------=_Part_29302_3720388.1229710001453 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline >  The coding standards are what's in the code -- I don't know of a
>  separate document.

Actually there's a CONTRIBUTING file in the DTN2 source repository that lays out the coding conventions. That should probably be copied back to the oasys directory as well. Also the part that names me as the maintainer of the software should also probably be updated :)

re:apache branch - fair enough I will give this a go. If this offers a
more portable approach to getting the exisintg code running on Win32
then that is good. I have come to the realisation that the current
code in the repository is likely not a good base at all; it looks to
be far too fixed to the capabilities of non-Win32 platforms. And it is
likely that a new implementation specifically for Win32 would likely
be the best way forward. But I really do not like giving up easily
which is why I completed the curent patch.

That's the reason I went down the apr-port route -- to get rid of the specific UNIX-isms from the code and instead program to the apr abstractions, and thereby make it easier for someone (like you) to go through the next step of getting things working on Win32 native.

So a further two questions, if I may, about development of the code:

1. Is there a roadmap detailing supported platforms, bug fixes etc?

Not really.
 
2. Is there any more information regarding the Apache "port"
available? (I did a quick search of the main site using the search but
nothing - am looking through the mail archives now)

Not really :)

My intent was to complete the port and then merge those changes back into the mainline.
Unfortunately I ran out of time in grad school and never finished the project, and now I'm onto other pursuits.

From what I remember of the status, I did get things most of the way there, including rewriting all the networking and file abstractions in oasys/io to use the apr wrappers, and I went through and updated at least the base DTN2 functionality to work with that. I also added a whole new mechanism for block caching of bundle payload data that makes things run much faster (since bundle data can be sent from memory without requiring it to be serialized to / from the disk).

There were certainly some things still unfinished, and I never even attempted building on Win32, but I agree strongly with Chris that going the apr-port route would be a much better approach than trying to maintain Win32 compatibility with the existing tip of the tree.

-m


------=_Part_29302_3720388.1229710001453-- Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mBJIKp8N028588 for ; Fri, 19 Dec 2008 10:20:52 -0800 Received: by ewy14 with SMTP id 14so1253978ewy.10 for ; Fri, 19 Dec 2008 09:47:42 -0800 (PST) Received: by 10.210.47.16 with SMTP id u16mr2764016ebu.16.1229708862906; Fri, 19 Dec 2008 09:47:42 -0800 (PST) Received: from ?192.168.1.101? (84-203-34-163.mysmart.ie [84.203.34.163]) by mx.google.com with ESMTPS id q9sm4496982gve.6.2008.12.19.09.47.41 (version=SSLv3 cipher=RC4-MD5); Fri, 19 Dec 2008 09:47:42 -0800 (PST) From: Alex McMahon To: Andy Scott In-Reply-To: References: <494BA456.2040506@bbn.com> Content-Type: text/plain Organization: Trinity College Dublin Date: Fri, 19 Dec 2008 17:47:39 +0000 Message-Id: <1229708859.7744.1.camel@sphere> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Cc: dtn-users Subject: Re: [dtn-users] Windows Build - Status Update X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: alex.mcmahon@cs.tcd.ie List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2008 18:20:52 -0000 it should be 'hg update apr-port' ~Alex On Fri, 2008-12-19 at 14:34 +0000, Andy Scott wrote: > OK updating the code to the Apache branch doing the following fails: > > mkdir apache > cd apache > hg clone http://dtn.sourceforge.net/hg/oasys > cd oasys > hd update apr-branch <----- fails > > The failure message is: abort: unknown revision 'apr-branch'! > > Andy Received: from yw-out-1718.google.com (yw-out-1718.google.com [74.125.46.155]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mBJF7YP8019774 for ; Fri, 19 Dec 2008 07:07:34 -0800 Received: by yw-out-1718.google.com with SMTP id 5so343377ywm.34 for ; Fri, 19 Dec 2008 06:34:29 -0800 (PST) Received: by 10.65.123.10 with SMTP id a10mr2478326qbn.79.1229697267902; Fri, 19 Dec 2008 06:34:27 -0800 (PST) Received: by 10.64.195.6 with HTTP; Fri, 19 Dec 2008 06:34:27 -0800 (PST) Message-ID: Date: Fri, 19 Dec 2008 14:34:27 +0000 From: "Andy Scott" To: dtn-users In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <494BA456.2040506@bbn.com> Subject: Re: [dtn-users] Windows Build - Status Update X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2008 15:07:34 -0000 OK updating the code to the Apache branch doing the following fails: mkdir apache cd apache hg clone http://dtn.sourceforge.net/hg/oasys cd oasys hd update apr-branch <----- fails The failure message is: abort: unknown revision 'apr-branch'! Andy -- Brain upgrade required: a working hypothalamus Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mBJEomt9018974 for ; Fri, 19 Dec 2008 06:50:48 -0800 Received: by an-out-0708.google.com with SMTP id d40so346684and.34 for ; Fri, 19 Dec 2008 06:17:43 -0800 (PST) Received: by 10.64.210.3 with SMTP id i3mr2481582qbg.30.1229696263519; Fri, 19 Dec 2008 06:17:43 -0800 (PST) Received: by 10.64.195.6 with HTTP; Fri, 19 Dec 2008 06:17:43 -0800 (PST) Message-ID: Date: Fri, 19 Dec 2008 14:17:43 +0000 From: "Andy Scott" To: "Christopher Small" In-Reply-To: <494BA456.2040506@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <494BA456.2040506@bbn.com> Cc: dtn-users Subject: Re: [dtn-users] Windows Build - Status Update X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2008 14:50:49 -0000 On 19/12/2008, Christopher Small wrote: > Andy Scott wrote: > > Q1. The patch is a touch big, ~107K, is there a patch review list I > > can send it to? > > Q2. It needs peer review - and my (many) mistakes pointed out - how do > > I find someone to do this? > > Q3. What coding standard is in place? I am going by the one I tend to > > use at my work: Unix line endings (except where VS2005 forces DOS), no > > tabs - spaces only, 4 space indent, always use {}'s ...... (any one > > looking at the patch will get my brain dead approach pretty quickly > > :-) ) > > Q4. If I ever manage to get the patch to a state it is acceptible then > > how do I commit? (This is *way* ahead of time but its nearly holiday > > time and I'm feeling optimistic) > > Are you working from a release tarball or the head of the tree? > > Send the patch to the project admins as listed on the sourceforge page. > Try to use the mercurial mechanisms and it'll be much easier for us to > check it out. > > Few of the project admins are heavy Windows hackers; do you have anyone > you know who is and could do a peer review? > > The coding standards are what's in the code -- I don't know of a > separate document. > > The code will have to be much further along than "I have chosen to hack > out functionality at this time to get it to compile" to get pushed back; > we try to keep the tree in a working state. > > You have only been working on this for a few days; I highly recommend > backing up and looking at the apache portable runtime branch. It will > probably work out better in the long run. > re:source - the head of the tree. re:reviewer - erm no. None that would know of this project's goals &c. re:"hacking" and tree working - well yes of course I understand that requirement to be paramount before pretty much all others. It was implicit in the plan I intended to follow: test it and make it work for Linux. Which I supose did read like I meant to do this only for each module after the main modifications were made. Modifying the tree to build for, as of yet, un-supported platform and breaking the supported ones for an un-specified amount of time is not the way to do any development. re:apache branch - fair enough I will give this a go. If this offers a more portable approach to getting the exisintg code running on Win32 then that is good. I have come to the realisation that the current code in the repository is likely not a good base at all; it looks to be far too fixed to the capabilities of non-Win32 platforms. And it is likely that a new implementation specifically for Win32 would likely be the best way forward. But I really do not like giving up easily which is why I completed the curent patch. So a further two questions, if I may, about development of the code: 1. Is there a roadmap detailing supported platforms, bug fixes etc? 2. Is there any more information regarding the Apache "port" available? (I did a quick search of the main site using the search but nothing - am looking through the mail archives now) andy -- Brain upgrade required: a working hypothalamus Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mBJEDgi4017237 for ; Fri, 19 Dec 2008 06:13:42 -0800 Received: from sneetch.bbn.com ([128.89.80.78]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LDfao-0004xL-A7; Fri, 19 Dec 2008 08:40:38 -0500 Message-ID: <494BA456.2040506@bbn.com> Date: Fri, 19 Dec 2008 08:40:38 -0500 From: Christopher Small User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Andy Scott References: In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6F6F97BB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dtn-users Subject: Re: [dtn-users] Windows Build - Status Update X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2008 14:13:43 -0000 Andy Scott wrote: > Q1. The patch is a touch big, ~107K, is there a patch review list I > can send it to? > Q2. It needs peer review - and my (many) mistakes pointed out - how do > I find someone to do this? > Q3. What coding standard is in place? I am going by the one I tend to > use at my work: Unix line endings (except where VS2005 forces DOS), no > tabs - spaces only, 4 space indent, always use {}'s ...... (any one > looking at the patch will get my brain dead approach pretty quickly > :-) ) > Q4. If I ever manage to get the patch to a state it is acceptible then > how do I commit? (This is *way* ahead of time but its nearly holiday > time and I'm feeling optimistic) Are you working from a release tarball or the head of the tree? Send the patch to the project admins as listed on the sourceforge page. Try to use the mercurial mechanisms and it'll be much easier for us to check it out. Few of the project admins are heavy Windows hackers; do you have anyone you know who is and could do a peer review? The coding standards are what's in the code -- I don't know of a separate document. The code will have to be much further along than "I have chosen to hack out functionality at this time to get it to compile" to get pushed back; we try to keep the tree in a working state. You have only been working on this for a few days; I highly recommend backing up and looking at the apache portable runtime branch. It will probably work out better in the long run. - Chris -- Dr. Christopher Small 617.873.6261 (vox) Networking Research 617.873.6091 (fax) BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138 Received: from yx-out-1718.google.com (yx-out-1718.google.com [74.125.44.152]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mBJ86kVL032486 for ; Fri, 19 Dec 2008 00:06:46 -0800 Received: by yx-out-1718.google.com with SMTP id 4so296491yxp.34 for ; Thu, 18 Dec 2008 23:33:49 -0800 (PST) Received: by 10.64.48.8 with SMTP id v8mr2204232qbv.78.1229672029314; Thu, 18 Dec 2008 23:33:49 -0800 (PST) Received: by 10.64.195.6 with HTTP; Thu, 18 Dec 2008 23:33:49 -0800 (PST) Message-ID: Date: Fri, 19 Dec 2008 07:33:49 +0000 From: "Andy Scott" To: dtn-users MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [dtn-users] Windows Build - Status Update X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2008 08:06:47 -0000 Obviously only of any importance who "like" Windows ;-) I have hacked the main line source of oasys such that it now compiles using VS2005 (I was already quite a bit through before I read the bit about using the Apache module branch and am just too stubborn to give up :) ) So some questions and a plan of my approach and caveats (and boy they're big): Questions: Q1. The patch is a touch big, ~107K, is there a patch review list I can send it to? Q2. It needs peer review - and my (many) mistakes pointed out - how do I find someone to do this? Q3. What coding standard is in place? I am going by the one I tend to use at my work: Unix line endings (except where VS2005 forces DOS), no tabs - spaces only, 4 space indent, always use {}'s ...... (any one looking at the patch will get my brain dead approach pretty quickly :-) ) Q4. If I ever manage to get the patch to a state it is acceptible then how do I commit? (This is *way* ahead of time but its nearly holiday time and I'm feeling optimistic) Plan of approach: 1. Get it to compile using VS2005 (both debug & release). 2. Go through the test directory and get each working in turn. 3. Fix any Windows/VS2005 specifics that have crept in by testing it against Linux. 4. Look to get the mods for each test reviewed and committed individually. Caveats: A. More than a few of the "make it compile" work arounds are probably going to turn heads/stomachs - sorry. I have chosen to hack out functionality at this time to get it to compile. B. I really, really *really* mean 'A' C. I have started a platform abstraction layer (nice to finally write one not for work purposes) that looks to remove the vaguaries of Linux/Win32 from the main code. For the moment it takes the form of a few files that define some function names, types, define symbols &c. This is only stage 0 of the creation of any such abstraction layer so is pretty crude at this time. Well I think that is it. Any replies or offers to review it would be good. [PS I managed to send this to the wrong dtn-users mail list earlier (joys of letting auto complete do its stuff) - so if anyone gets two copies sorry] Andy -- Brain upgrade required: a working hypothalamus Received: from lax-mailout1.raytheon.com (lax-mailout1.raytheon.com [199.46.200.198]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mBJ0Tiqn011805 for ; Thu, 18 Dec 2008 16:29:44 -0800 Received: from dmoutw00.directory.ray.com (dmoutw00.directory.ray.com [147.25.146.122]) by lax-mailout1.raytheon.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id mBINuLB0015703 for ; Thu, 18 Dec 2008 23:56:21 GMT Received: from dmsmtpw00.directory.ray.com (dmsmtpw00.directory.ray.com [147.25.146.123]) by dmoutw00.directory.ray.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id mBINuWHs030738 sender Sung_Park@raytheon.com for ; Thu, 18 Dec 2008 23:56:32 GMT Received: from es2-msg02.raymail.ray.com (es2-msg02.ess.us.ray.com [147.16.196.99]) by dmsmtpw00.directory.ray.com (8.12.11/8.12.11) with ESMTP id mBINui73028166 sender Sung_Park@raytheon.com for ; Thu, 18 Dec 2008 23:56:44 GMT Received: from ZFUAD312962 ([147.19.104.159]) by es2-msg02.raymail.ray.com (Lotus Domino Release 8.0.2) with ESMTP id 2008121815564281-541 ; Thu, 18 Dec 2008 15:56:42 -0800 From: "Sung Park" To: "'Bush, Jeff'" , References: <001a01c96085$04667470$0d335d50$@com> <29705F5F232FBC4C96D1CAE867538F0B0A71346CAA@IMCMBX4.MITRE.ORG> In-Reply-To: <29705F5F232FBC4C96D1CAE867538F0B0A71346CAA@IMCMBX4.MITRE.ORG> Date: Thu, 18 Dec 2008 15:56:39 -0800 Organization: Raytheon Message-ID: <003601c9616c$44fbba80$cef32f80$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: AclghQQh9f59RjTiQn+rEnStM110IwAohHBQABCd3IA= X-MIMETrack: Itemize by SMTP Server on ES2-MSG02/SRV/Raytheon(Release 8.0.2|August 07, 2008) at 12/18/2008 15:56:43, Serialize by Router on ES2-MSG02/SRV/Raytheon(Release 8.0.2|August 07, 2008) at 12/18/2008 15:56:44, Serialize complete at 12/18/2008 15:56:44 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0037_01C96129.36D87A80" Content-Language: en-us Subject: Re: [dtn-users] NORM CL multicast session configuration question X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Sung_Park@raytheon.com List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2008 00:29:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0037_01C96129.36D87A80 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Hi Jeff, Thanks for your reply. I was able to get the multicast session working using your configuration example. However, I had to again use the local_addr field option for "link add" configuration line. So my line look like the following link add multicast_link 239.255.0.1:4558 ALWAYSON norm local_addr=239.255.0.1 multicast_interface=eth0 remote_eid=dtn://mgroup I'm not sure what is specific about my setup that is requiring that option. I have a simple network setup where three machines are connected to a common LAN via Ethernet bridge. I am doing most of my experiment using VMs, so it may have something to do with it. But so far, except the extra option, I have three nodes all multicasting to each other using NORM CL. Very cool. I will perform more experiments with it, and if I find out anything interesting, I will make sure to share it with everyone in the group. One thing that I noticed was that NORM CL doesn't seem to work with Bonjour. Do you have any plan to include neighbor discovery functionality on top of NORM? If you can share your future plan for NORM CL, I would appreciate it as well. Thanks again. Sung From: Bush, Jeff [mailto:jbush@mitre.org] Sent: Thursday, December 18, 2008 8:39 AM To: Sung_Park@raytheon.com; dtn-users@maillists.intel-research.net Subject: RE: [dtn-users] NORM CL multicast session configuration question Hi Sung, For unicast norm links, the local_addr parameter value is used to uniquely identify the dtn node in a norm session. (There's one norm session per unicast link.) I'm really just looking for a norm session unique 32-bit number - not necessarily an IP address. If not specified the norm engine will use the computer's "default" ip address to identify the dtn node's presence in the session. To understand exactly why you needed to use the local_addr parameter, I'd need to know more about your test network. Here's how to configure a one-to-many multicast norm link (i.e. last-hop DTN fanout). On your receiver nodes, add norm interfaces with something like: interface add norm0 norm multicast_interface=eth0 By default, this will cause dtnd to join the multicast group 239.255.0.1 on interface eth0. If you want to join a different multicast group, use the local_addr parameter. Here, the local_addr parameter actually needs to be a multicast IP address. interface add norm0 norm multicast_interface=eth0 local_addr=224.0.1.20 Norm interfaces listen on port 4558 by default. Currently, this is hard-coded. On the sending side, add a multicast link. For example: link add multicast_link 239.255.0.1:4558 ALWAYSON norm multicast_interface=eth0 remote_eid=dtn://mgroup Test using dtnsend/dtnrecv. With dtnrecv, you can register whatever destination eid you choose - it doesn't have to be related to the local_eid of the local dtn daemon. On your receiver nodes, try: dtnrecv dtn://mgroup Now you should be able to multicast a file using dtnsend to the destination eid dtn://mgroup -Jeff From: dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users-bounces@maillists.intel-research.net] On Behalf Of Sung Park Sent: Wednesday, December 17, 2008 3:21 PM To: dtn-users@maillists.intel-research.net Subject: [dtn-users] NORM CL multicast session configuration question Hi all, I just learned of the inclusion of NORM CL into DTN and jumped in right away. Got a clean install on ubuntu x86-32bit as a previous poster has indicated. I did notice that on the link add option, I had to add local addr field to get the ping working. So instead of adding "link add norm_link remote_host:4557 ALWASYON norm" as the doc suggested, I had to use the following line "link add norm_link remote_host:4557 ALWASYON norm local_addr=". Not sure if anybody else has experienced the same issue. I am also wondering how to setup the CL for a multicast session. I was trying to create a multicast session by creating a multicast group with three nodes all sharing a common NORM link to the multicast group. Would this be possible with the current implementation? Or would the multicast sender need to create a separate link per receiver to be able to perform multicast transmission. If it's the latter case, I have to assume that NORM CL is solely for transport mechanism and not as a mechanism to create multicast session. Is that true? I did see the multicast_interface link option in the document. Any example of how to setup a multicast session using NORM CL is greatly appreciated. Thanks. Regards, Sung ------=_NextPart_000_0037_01C96129.36D87A80 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="US-ASCII"

Hi Jeff,

 

Thanks for your reply.  I was able to get the multicast session working = using your configuration example.  However, I had to again use the = local_addr field option for “link add” configuration line.  So my = line look like the following

 

link add multicast_link 239.255.0.1:4558 ALWAYSON norm = local_addr=3D239.255.0.1 multicast_interface=3Deth0 = remote_eid=3Ddtn://mgroup

 

I’m not sure what is specific about my setup that is requiring that option. =   I have a simple network setup where three machines are connected to a = common LAN via Ethernet bridge.  I am doing most of my experiment using VMs, = so it may have something to do with it.  But so far, except the extra = option, I have three nodes all multicasting to each other using NORM CL. Very = cool.   I will perform more experiments with it, and if I find out anything = interesting, I will make sure to share it with everyone in the group.   One = thing that I noticed was that NORM CL doesn’t seem to work with = Bonjour.  Do you have any plan to include neighbor discovery functionality on top = of NORM?  If you can share your future plan for NORM CL, I would = appreciate it as well.   Thanks again.

 

Sung<= /span>

 

 

From:= Bush, Jeff [mailto:jbush@mitre.org]
Sent: Thursday, December 18, 2008 8:39 AM
To: Sung_Park@raytheon.com; = dtn-users@maillists.intel-research.net
Subject: RE: [dtn-users] NORM CL multicast session configuration question

 

Hi Sung,

 

For unicast norm links, the local_addr parameter value is = used to uniquely identify the dtn node in a norm session.  (There’s = one norm session per unicast link.)  I’m really just looking for a = norm session unique 32-bit number – not necessarily an IP = address.  If not specified the norm engine will use the computer’s “default” ip address to identify the dtn node’s = presence in the session.  To understand exactly why you needed to use the = local_addr parameter, I’d need to know more about your test = network.

 

Here’s how to configure a one-to-many multicast norm = link (i.e. last-hop DTN fanout).  On your receiver nodes, add norm = interfaces with something like:

 

interface add norm0 norm = multicast_interface=3Deth0

 

By default, this will cause dtnd to join the multicast group = 239.255.0.1 on interface eth0.  If you want to join a different multicast = group, use the local_addr parameter.  Here, the local_addr parameter actually = needs to be a multicast IP address.

 

interface add norm0 norm multicast_interface=3Deth0 = local_addr=3D224.0.1.20

 

Norm interfaces listen on port 4558 by default.  = Currently, this is hard-coded.  On the sending side, add a multicast = link.  For example:

 

link add multicast_link 239.255.0.1:4558 ALWAYSON norm multicast_interface=3Deth0 = remote_eid=3Ddtn://mgroup

 

Test using dtnsend/dtnrecv.  With dtnrecv, you can = register whatever destination eid you choose – it doesn’t have to be = related to the local_eid of the local dtn daemon.  On your receiver nodes, = try:

 

dtnrecv dtn://mgroup

 

Now you should be able to multicast a file using dtnsend to = the destination eid dtn://mgroup

 

-Jeff

 

From:= dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users-bounces@maillists.intel-research.net] On Behalf Of = Sung Park
Sent: Wednesday, December 17, 2008 3:21 PM
To: dtn-users@maillists.intel-research.net
Subject: [dtn-users] NORM CL multicast session configuration = question

 

Hi = all,

 

I = just learned of the inclusion of NORM CL into DTN and jumped in right = away.  Got a clean install on ubuntu x86-32bit as a previous poster has = indicated.  I did notice that on the link add option, I had to add local addr field = to get the ping working.  So instead of adding “link add norm_link remote_host:4557 ALWASYON norm” as the doc suggested, I had to use = the following line “link add norm_link remote_host:4557 ALWASYON norm local_addr=3D<my local ip>”.  Not sure if anybody else = has experienced the same issue. 

 

I = am also wondering how to setup the CL for a multicast session.  I was = trying to create a multicast session by creating a multicast group with three = nodes all sharing a common NORM link to the multicast group.  Would this be = possible with the current implementation?  Or would the multicast sender = need to create a separate link per receiver to be able to perform multicast transmission.  If it’s the latter case, I have to assume that = NORM CL is solely for transport mechanism and not as a mechanism to create = multicast session.  Is that true?  I did see the multicast_interface = link option in the document.  Any example of how to setup a multicast = session using NORM CL is greatly appreciated.  Thanks. =

 

Regards, =

 

Sung

 

 

 

------=_NextPart_000_0037_01C96129.36D87A80-- Received: from mail-bw0-f12.google.com (mail-bw0-f12.google.com [209.85.218.12]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mBIISCWx027938 for ; Thu, 18 Dec 2008 10:28:12 -0800 Received: by bwz5 with SMTP id 5so1383557bwz.10 for ; Thu, 18 Dec 2008 09:55:29 -0800 (PST) Received: by 10.223.111.71 with SMTP id r7mr1957951fap.59.1229622745943; Thu, 18 Dec 2008 09:52:25 -0800 (PST) Received: by 10.223.107.211 with HTTP; Thu, 18 Dec 2008 09:52:25 -0800 (PST) Message-ID: <4bfc0da50812180952i564d0598p659bafd999a1333d@mail.gmail.com> Date: Thu, 18 Dec 2008 17:52:25 +0000 From: "Ricardo Martins" To: "Krupiarz, Christopher" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: dtn-users@maillists.intel-research.net Subject: Re: [dtn-users] getting dtn2 to build on Ubuntu 8.10 (really gcc 4.3.2) X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2008 18:28:13 -0000 Hi, This is already fixed in the development repository. The lines you refer to were changed to something like: oasys_cv_prog_gccver=`$CC -dumpversion | cut -f1-2 -d.` Regards, Ricardo Martins 2008/12/18 Krupiarz, Christopher : > Not sure if this has been resolved yet, but I didn't see it in the > archives so I thought I'd pass this along. I had the same issue with > Ubuntu yesterday and the source of the problem is in > oasys*/aclocal/gcc.ac. Here's an except: > > dnl > dnl Figure out the version and set version-specific options > dnl > AC_CACHE_CHECK(for the version of the GNU C compiler, > oasys_cv_prog_gccver, [ > oasys_cv_prog_gccver=`$CC --version | head -n 1` > oasys_cv_prog_gccver=`echo $oasys_cv_prog_gccver | sed 's/.*gcc.*(GCC) //'` > oasys_cv_prog_gccver=`echo $oasys_cv_prog_gccver | sed 's/ .*//'` > ]) > > AC_CACHE_CHECK(for the version of the GNU C++ compiler, > oasys_cv_prog_gxxver, [ > oasys_cv_prog_gxxver=`$CXX --version | head -n 1` > oasys_cv_prog_gxxver=`echo $oasys_cv_prog_gxxver | sed > 's/.*g++.*(GCC) //'` > oasys_cv_prog_gxxver=`echo $oasys_cv_prog_gxxver | sed 's/ .*//'` > ]) > > Where it says "(GCC)" it should say something like (.*). > > This is because "gcc --version" on, for instance, one of our SuSE > machines produces: > > gcc (GCC) 4.4.1 > > Whereas on Ubuntu, it produces: > > gcc (Ubuntu 4.3.2-1ubuntu11) 4.3.2 > > Thus, the version number is not properly parsed. (Thanks to a colleague > of mine for figuring this out) > > > Chris > > ==== > > Hi, > > Usually something like "gcc -dumpversion | cut -f1-2 -d" does the > trick to get the relevant version of gcc (or g++). > I've sent you the dump files of 9 gcc versions as requested. > > Regards, > Ricardo Martins > > 2008/11/18 Christopher Small >: >> DTN2 does not build out-of-the-box on a stock Ubuntu 8.10 machine. > I've >> got some candidate fixes, and to see if I've done the right thing it >> would be helpful to get a small amount of data from a large variety of >> machines. >> >> If you would be so kind as to email me (and not the entire list) the >> output of "gcc -v" and "g++ -v" on your machine (Mac, Linux, BSD, >> Cygwin, ...) I would be very grateful. >> >> running the following should do the job, if you have mail configured > on >> your machine. >> >> $ (uname -a ; gcc -v 2>&1 ; g++ -v 2>&1) | mail csmall at bbn.com > >> >> Otherwise running the following, followed by a cut-and-paste into a > mail >> composition window, should work. >> >> $ (uname -a ; gcc -v 2>&1 ; g++ -v 2>&1) >> >> Thanks. >> >> - Chris >> >> -- >> Dr. Christopher Small 617.873.6261 (vox) >> Networking Research 617.873.6091 (fax) >> BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138 > > _______________________________________________ > dtn-users mailing list > dtn-users@maillists.intel-research.net > http://maillists.intel-research.net/mailman/listinfo/dtn-users > Received: from jhuapl.edu (pilot.jhuapl.edu [128.244.198.200]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mBIHsbY1026412 for ; Thu, 18 Dec 2008 09:54:38 -0800 Received: from ([128.244.198.158]) by pilot.jhuapl.edu with ESMTP id 5502123.128903937; Thu, 18 Dec 2008 12:21:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 18 Dec 2008 12:21:39 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: getting dtn2 to build on Ubuntu 8.10 (really gcc 4.3.2) Thread-Index: AclhNRaBDY3257XPQzWNXS2gkb3wGg== From: "Krupiarz, Christopher" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id mBIHsbY1026412 Subject: Re: [dtn-users] getting dtn2 to build on Ubuntu 8.10 (really gcc 4.3.2) X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2008 17:54:38 -0000 Not sure if this has been resolved yet, but I didn't see it in the archives so I thought I'd pass this along. I had the same issue with Ubuntu yesterday and the source of the problem is in oasys*/aclocal/gcc.ac. Here's an except: dnl dnl Figure out the version and set version-specific options dnl AC_CACHE_CHECK(for the version of the GNU C compiler, oasys_cv_prog_gccver, [ oasys_cv_prog_gccver=`$CC --version | head -n 1` oasys_cv_prog_gccver=`echo $oasys_cv_prog_gccver | sed 's/.*gcc.*(GCC) //'` oasys_cv_prog_gccver=`echo $oasys_cv_prog_gccver | sed 's/ .*//'` ]) AC_CACHE_CHECK(for the version of the GNU C++ compiler, oasys_cv_prog_gxxver, [ oasys_cv_prog_gxxver=`$CXX --version | head -n 1` oasys_cv_prog_gxxver=`echo $oasys_cv_prog_gxxver | sed 's/.*g++.*(GCC) //'` oasys_cv_prog_gxxver=`echo $oasys_cv_prog_gxxver | sed 's/ .*//'` ]) Where it says "(GCC)" it should say something like (.*). This is because "gcc --version" on, for instance, one of our SuSE machines produces: gcc (GCC) 4.4.1 Whereas on Ubuntu, it produces: gcc (Ubuntu 4.3.2-1ubuntu11) 4.3.2 Thus, the version number is not properly parsed. (Thanks to a colleague of mine for figuring this out) Chris ==== Hi, Usually something like "gcc -dumpversion | cut -f1-2 -d" does the trick to get the relevant version of gcc (or g++). I've sent you the dump files of 9 gcc versions as requested. Regards, Ricardo Martins 2008/11/18 Christopher Small >: > DTN2 does not build out-of-the-box on a stock Ubuntu 8.10 machine. I've > got some candidate fixes, and to see if I've done the right thing it > would be helpful to get a small amount of data from a large variety of > machines. > > If you would be so kind as to email me (and not the entire list) the > output of "gcc -v" and "g++ -v" on your machine (Mac, Linux, BSD, > Cygwin, ...) I would be very grateful. > > running the following should do the job, if you have mail configured on > your machine. > > $ (uname -a ; gcc -v 2>&1 ; g++ -v 2>&1) | mail csmall at bbn.com > > Otherwise running the following, followed by a cut-and-paste into a mail > composition window, should work. > > $ (uname -a ; gcc -v 2>&1 ; g++ -v 2>&1) > > Thanks. > > - Chris > > -- > Dr. Christopher Small 617.873.6261 (vox) > Networking Research 617.873.6091 (fax) > BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138 Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mBIHC02k024485 for ; Thu, 18 Dec 2008 09:12:01 -0800 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBIGdKn6015331 for ; Thu, 18 Dec 2008 11:39:20 -0500 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBIGdJWt015320; Thu, 18 Dec 2008 11:39:19 -0500 Received: from IMCMBX4.MITRE.ORG ([129.83.29.207]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Thu, 18 Dec 2008 11:39:19 -0500 From: "Bush, Jeff" To: "Sung_Park@raytheon.com" , "dtn-users@maillists.intel-research.net" Date: Thu, 18 Dec 2008 11:39:16 -0500 Thread-Topic: [dtn-users] NORM CL multicast session configuration question Thread-Index: AclghQQh9f59RjTiQn+rEnStM110IwAohHBQ Message-ID: <29705F5F232FBC4C96D1CAE867538F0B0A71346CAA@IMCMBX4.MITRE.ORG> References: <001a01c96085$04667470$0d335d50$@com> In-Reply-To: <001a01c96085$04667470$0d335d50$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01C96105.3FAA83C0" MIME-Version: 1.0 Subject: Re: [dtn-users] NORM CL multicast session configuration question X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2008 17:12:01 -0000 ------=_NextPart_000_0000_01C96105.3FAA83C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_01C96105.3FAA83C0" ------=_NextPart_001_0001_01C96105.3FAA83C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Sung, For unicast norm links, the local_addr parameter value is used to uniquely identify the dtn node in a norm session. (There's one norm session per unicast link.) I'm really just looking for a norm session unique 32-bit number - not necessarily an IP address. If not specified the norm engine will use the computer's "default" ip address to identify the dtn node's presence in the session. To understand exactly why you needed to use the local_addr parameter, I'd need to know more about your test network. Here's how to configure a one-to-many multicast norm link (i.e. last-hop DTN fanout). On your receiver nodes, add norm interfaces with something like: interface add norm0 norm multicast_interface=eth0 By default, this will cause dtnd to join the multicast group 239.255.0.1 on interface eth0. If you want to join a different multicast group, use the local_addr parameter. Here, the local_addr parameter actually needs to be a multicast IP address. interface add norm0 norm multicast_interface=eth0 local_addr=224.0.1.20 Norm interfaces listen on port 4558 by default. Currently, this is hard-coded. On the sending side, add a multicast link. For example: link add multicast_link 239.255.0.1:4558 ALWAYSON norm multicast_interface=eth0 remote_eid=dtn://mgroup Test using dtnsend/dtnrecv. With dtnrecv, you can register whatever destination eid you choose - it doesn't have to be related to the local_eid of the local dtn daemon. On your receiver nodes, try: dtnrecv dtn://mgroup Now you should be able to multicast a file using dtnsend to the destination eid dtn://mgroup -Jeff From: dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users-bounces@maillists.intel-research.net] On Behalf Of Sung Park Sent: Wednesday, December 17, 2008 3:21 PM To: dtn-users@maillists.intel-research.net Subject: [dtn-users] NORM CL multicast session configuration question Hi all, I just learned of the inclusion of NORM CL into DTN and jumped in right away. Got a clean install on ubuntu x86-32bit as a previous poster has indicated. I did notice that on the link add option, I had to add local addr field to get the ping working. So instead of adding "link add norm_link remote_host:4557 ALWASYON norm" as the doc suggested, I had to use the following line "link add norm_link remote_host:4557 ALWASYON norm local_addr=". Not sure if anybody else has experienced the same issue. I am also wondering how to setup the CL for a multicast session. I was trying to create a multicast session by creating a multicast group with three nodes all sharing a common NORM link to the multicast group. Would this be possible with the current implementation? Or would the multicast sender need to create a separate link per receiver to be able to perform multicast transmission. If it's the latter case, I have to assume that NORM CL is solely for transport mechanism and not as a mechanism to create multicast session. Is that true? I did see the multicast_interface link option in the document. Any example of how to setup a multicast session using NORM CL is greatly appreciated. Thanks. Regards, Sung ------=_NextPart_001_0001_01C96105.3FAA83C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sung,

 

For unicast norm links, the local_addr parameter value is = used to uniquely identify the dtn node in a norm session.  (There’s one norm = session per unicast link.)  I’m really just looking for a norm = session unique 32-bit number – not necessarily an IP address.  If not = specified the norm engine will use the computer’s “default” ip = address to identify the dtn node’s presence in the session.  To = understand exactly why you needed to use the local_addr parameter, I’d need = to know more about your test network.

 

Here’s how to configure a one-to-many multicast norm = link (i.e. last-hop DTN fanout).  On your receiver nodes, add norm interfaces = with something like:

 

interface add norm0 norm = multicast_interface=3Deth0

 

By default, this will cause dtnd to join the multicast group 239.255.0.1 on interface eth0.  If you want to join a different = multicast group, use the local_addr parameter.  Here, the local_addr = parameter actually needs to be a multicast IP address.

 

interface add norm0 norm multicast_interface=3Deth0 = local_addr=3D224.0.1.20

 

Norm interfaces listen on port 4558 by default.  = Currently, this is hard-coded.  On the sending side, add a multicast link.  = For example:

 

link add multicast_link 239.255.0.1:4558 ALWAYSON norm multicast_interface=3Deth0 = remote_eid=3Ddtn://mgroup

 

Test using dtnsend/dtnrecv.  With dtnrecv, you can = register whatever destination eid you choose – it doesn’t have to be = related to the local_eid of the local dtn daemon.  On your receiver nodes, = try:

 

dtnrecv dtn://mgroup

 

Now you should be able to multicast a file using dtnsend to = the destination eid dtn://mgroup

 

-Jeff

 

From:= dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users-bounces@maillists.intel-research.net] On Behalf Of = Sung Park
Sent: Wednesday, December 17, 2008 3:21 PM
To: dtn-users@maillists.intel-research.net
Subject: [dtn-users] NORM CL multicast session configuration = question

 

Hi = all,

 

I = just learned of the inclusion of NORM CL into DTN and jumped in right = away.  Got a clean install on ubuntu x86-32bit as a previous poster has indicated.  I did notice that on the link add option, I had to add = local addr field to get the ping working.  So instead of adding = “link add norm_link remote_host:4557 ALWASYON norm” as the doc suggested, I = had to use the following line “link add norm_link remote_host:4557 = ALWASYON norm local_addr=3D<my local ip>”.  Not sure if anybody else = has experienced the same issue. 

 

I = am also wondering how to setup the CL for a multicast session.  I was = trying to create a multicast session by creating a multicast group with three = nodes all sharing a common NORM link to the multicast group.  Would this be = possible with the current implementation?  Or would the multicast sender = need to create a separate link per receiver to be able to perform multicast transmission.  If it’s the latter case, I have to assume that = NORM CL is solely for transport mechanism and not as a mechanism to create = multicast session.  Is that true?  I did see the multicast_interface = link option in the document.  Any example of how to setup a multicast = session using NORM CL is greatly appreciated.  Thanks. =

 

Regards, =

 

Sung

 

 

 

------=_NextPart_001_0001_01C96105.3FAA83C0-- ------=_NextPart_000_0000_01C96105.3FAA83C0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKtTCCA2Ew ggJJoAMCAQICAhwzMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMDgwNjI3MjA0NTEyWhcNMDkxMjE5MjA0NTEyWjBWMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEVMBMGCgmSJomT8ixkAQETBWpidXNoMRgwFgYDVQQDEw9C dXNoIEplZmZyZXkgRC4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKIAhldyfonlF/aWaHLg Fqhw1QV2YBkox11Fw98vgjGvJTfsdwwSnP6mxH5HLiDAcpv3FTTQnC2SB/YxeAegPoqIktceA2Ww 2acTpQLp1DHulcxtnEG3pmv6AwpGO77hUcVVF2lC7czF5j9t/m3H9hnYxmqcBx77JGyES060+7MZ AgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQWBBTLCLnhPmFRXByDup1S/jysjuv4 VzAfBgNVHSMEGDAWgBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRw Oi8vd3d3Lm1pdHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwGgYDVR0RBBMw EYEPamJ1c2hAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAoqGuAriAsuQmR98gd5/VVc15H D579SdtvzosVljwgZXX9FI/aniCw1rt7cryWIVbblk5gteOPWiUAR2XVA0M+FLA0TWOz9bDxJZlh CJ/tGTXIMrnlO5Ea2cTTviNH4s9uvNwp53u//U3pcuciVW5xPS+Y8vlB87oSkHI73uJYk2nfzNUB /kvMj8oLVkElyBWAUvdvG+B4aJL6WVoI3OJAQjx9UnSWDooqSVIhc9kdDRzx4Kt6IsXqwYWmj1OZ qQaYmJY3b2s45zd/rBlFjIyVpyyi2G3xhgQTlubDg5QiSCJQrpqA/G8cbydsNBquRM3o/0QyQgML vn5N4D905dzlMIIDZDCCAkygAwIBAgIBATANBgkqhkiG9w0BAQUFADBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEkMCIGA1UEAxMbTUlUUkUgQ29y cG9yYXRpb24gUm9vdCBDQS0xMB4XDTA2MDYwMTA0MDAwMFoXDTE4MDYwMTA0MDAwMFowWjESMBAG A1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJDAiBgNVBAMT G01JVFJFIENvcnBvcmF0aW9uIFJvb3QgQ0EtMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAK9rWpY9mIQm/m8y0JuO3RxO7Q1ufXlDVwqpAFcqLxVIf3Nk+Y/F9aLMknslKoUnn+wtTPc2 ydRWOktgF0VzE1ec4uNe2YM8U57CblP3w1lz3BFEKIPO3h/yqwcUjX1KE+Irdw3lSq0l/6LrpBUs DVLoI0vqjZ4YCwCXlafHA6HYF9xZTl82UcNVz0ooCUMNakeMLYsscBRss/hnMwgkpwuAsoUy2AzY AR9pIfOaLtZR1QdEK0JuWsXurM+zL+MEsWuvxVxf6Zvuxqr3mkQ6KWByLHT+dpbuQl8zmmHtQEH5 LU786Ef5mNDgyNafATwD9gOtDHU5UsA6Lb0GyGj+XyUCAwEAAaM1MDMwEgYDVR0TAQH/BAgwBgEB /wIBAzAdBgNVHQ4EFgQUx3BRANhN/uQB1GiWxT2fmpf+dC8wDQYJKoZIhvcNAQEFBQADggEBABr5 9V8KWOKYGVx9bCR8le5c0pa6f3GWgUqOerpI8aAAgqLktQOKXrRrQ1o0agZI7cjXHNi3udxrKHbW pe6VxVMMWq5tIl2/nVodO4lhxhRfvYs3+BKrTdRUsEInNibtktSWRvZgujvFR5ndygsVxPkAdHfq SMbhxgepeAfSWIGXyPGk3SDCBpyLiyA8tSPXDi3zOgof7PEYXBfBM/8/561CqIlnlPTR8submTP2 aafHGaYi9QY12wICEaF2cXbilytHjcs2DI4En0M9QcE2reRRBE7jxYErEHF+U60rOwgLH8cS0gAF xmft14AMdxj2ylQtl8GdBh0SnLPm2CHtjaowggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUA MFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcNMTIw NjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPnhlflKPFPMXGG+iqG pImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI7fnUWiUasNP2ING19aAf rQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407K1i+7WnrRsMVKhICfgmiO/Xi VR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClHDtPJs7UOTjMYBS2fTzztC+wwOTp6 +A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQAB o4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYDVR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9I jWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAWgBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8E QTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1pdHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRy ZV9vcmcuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IA e7u60LK0V9jVZ9E2a+c0MZiSojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8 WDPzlud/WQAzkjrU2nuh8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680 ukiJ9yF6UmEXuciB77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXt p3DIrVqE/DZr146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7Nqg MYICvTCCArkCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRl IEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIcMzAJ BgUrDgMCGgUAoIIBsDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w ODEyMTgxNjM5MTJaMCMGCSqGSIb3DQEJBDEWBBRfeRxIBjFCY12lJ1eavsXMP49fTDBnBgkqhkiG 9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTByBgkrBgEEAYI3EAQxZTBj MF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScw JQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAhwzMHQGCyqGSIb3DQEJEAIL MWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIcMzANBgkqhkiG9w0B AQEFAASBgA9csI4nL1JNb8WXrC4Xdn541GXqyX08HYi8kkwj7W2rrpvqmIjvcHfJ2hjAX8Z8zr9p 9yhlqqZFwCIgydv0YCXJRM4OcAYAr+2Xn1s71zS5zeixgb4RnZ+e/PwgJJgPUQbbZ4O5unxH8Ws1 5XKdWmkRH+GxNgXW1pTLi7Lp9f7GAAAAAAAA ------=_NextPart_000_0000_01C96105.3FAA83C0-- Received: from mail-gx0-f13.google.com (mail-gx0-f13.google.com [209.85.217.13]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mBIGJfQk022146 for ; Thu, 18 Dec 2008 08:19:42 -0800 Received: by gxk6 with SMTP id 6so496221gxk.13 for ; Thu, 18 Dec 2008 07:47:02 -0800 (PST) Received: by 10.64.220.20 with SMTP id s20mr1631929qbg.47.1229615221269; Thu, 18 Dec 2008 07:47:01 -0800 (PST) Received: by 10.64.195.6 with HTTP; Thu, 18 Dec 2008 07:47:01 -0800 (PST) Message-ID: Date: Thu, 18 Dec 2008 15:47:01 +0000 From: "Andy Scott" To: dtn-users@mailman.dtnrg.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [dtn-users] Windows Build - Status Update X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2008 16:19:42 -0000 Obviously only of any importance who "like" Windows ;-) I have hacked the main line source of oasys such that it now compiles using VS2005 (I was already quite a bit through before I read the bit about using the Apache module branch and am just too stubborn to give up :) ) So some questions and a plan of my approach and caveats (and boy they're big): Questions: Q1. The patch is a touch big, ~107K, is there a patch review list I can send it to? Q2. It needs peer review - and my (many) mistakes pointed out - how do I find someone to do this? Q3. What coding standard is in place? I am going by the one I tend to use at my work: Unix line endings (except where VS2005 forces DOS), no tabs - spaces only, 4 space indent, always use {}'s ...... (any one looking at the patch will get my brain dead approach pretty quickly :-) ) Q4. If I ever manage to get the patch to a state it is acceptible then how do I commit? (This is *way* ahead of time but its nearly holiday time and I'm feeling optimistic) Plan of approach: 1. Get it to compile using VS2005 (both debug & release). 2. Go through the test directory and get each working in turn. 3. Fix any Windows/VS2005 specifics that have crept in by testing it against Linux. 4. Look to get the mods for each test reviewed and committed individually. Caveats: A. More than a few of the "make it compile" work arounds are probably going to turn heads/stomachs - sorry. I have chosen to hack out functionality at this time to get it to compile. B. I really, really *really* mean 'A' C. I have started a platform abstraction layer (nice to finally write one not for work purposes) that looks to remove the vaguaries of Linux/Win32 from the main code. For the moment it takes the form of a few files that define some function names, types, define symbols &c. This is only stage 0 of the creation of any such abstraction layer so is pretty crude at this time. Well I think that is it. Any replies or offers to review it would be good. Andy -- Brain upgrade required: a working hypothalamus Received: from lax-mailout1.raytheon.com (lax-mailout1.raytheon.com [199.46.200.198]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mBHKsAiS001348 for ; Wed, 17 Dec 2008 12:54:10 -0800 Received: from dmoutw00.directory.ray.com (dmoutw00.directory.ray.com [147.25.146.122]) by lax-mailout1.raytheon.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id mBHKL1iO013528 for ; Wed, 17 Dec 2008 20:21:17 GMT Received: from dmsmtpw00.directory.ray.com (dmsmtpw00.directory.ray.com [147.25.146.123]) by dmoutw00.directory.ray.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id mBHKL9DC012274 sender Sung_Park@raytheon.com for ; Wed, 17 Dec 2008 20:21:28 GMT Received: from es2-msg02.raymail.ray.com (es2-msg02.ess.us.ray.com [147.16.196.99]) by dmsmtpw00.directory.ray.com (8.12.11/8.12.11) with ESMTP id mBHKLMFB027650 sender Sung_Park@raytheon.com for ; Wed, 17 Dec 2008 20:21:22 GMT Received: from ZFUAD312962 ([147.19.104.159]) by es2-msg02.raymail.ray.com (Lotus Domino Release 8.0.2) with ESMTP id 2008121712212008-402 ; Wed, 17 Dec 2008 12:21:20 -0800 From: "Sung Park" To: Date: Wed, 17 Dec 2008 12:21:17 -0800 Organization: Raytheon Message-ID: <001a01c96085$04667470$0d335d50$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: AclghQQh9f59RjTiQn+rEnStM110Iw== X-MIMETrack: Itemize by SMTP Server on ES2-MSG02/SRV/Raytheon(Release 8.0.2|August 07, 2008) at 12/17/2008 12:21:20, Serialize by Router on ES2-MSG02/SRV/Raytheon(Release 8.0.2|August 07, 2008) at 12/17/2008 12:21:22, Serialize complete at 12/17/2008 12:21:22 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C96041.F6433470" Content-Language: en-us Subject: [dtn-users] NORM CL multicast session configuration question X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Sung_Park@raytheon.com List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2008 20:54:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001B_01C96041.F6433470 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Hi all, I just learned of the inclusion of NORM CL into DTN and jumped in right away. Got a clean install on ubuntu x86-32bit as a previous poster has indicated. I did notice that on the link add option, I had to add local addr field to get the ping working. So instead of adding "link add norm_link remote_host:4557 ALWASYON norm" as the doc suggested, I had to use the following line "link add norm_link remote_host:4557 ALWASYON norm local_addr=". Not sure if anybody else has experienced the same issue. I am also wondering how to setup the CL for a multicast session. I was trying to create a multicast session by creating a multicast group with three nodes all sharing a common NORM link to the multicast group. Would this be possible with the current implementation? Or would the multicast sender need to create a separate link per receiver to be able to perform multicast transmission. If it's the latter case, I have to assume that NORM CL is solely for transport mechanism and not as a mechanism to create multicast session. Is that true? I did see the multicast_interface link option in the document. Any example of how to setup a multicast session using NORM CL is greatly appreciated. Thanks. Regards, Sung ------=_NextPart_000_001B_01C96041.F6433470 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="US-ASCII"

Hi = all,

 

I = just learned of the inclusion of NORM CL into DTN and jumped in right = away.  Got a clean install on ubuntu x86-32bit as a previous poster has = indicated.  I did notice that on the link add option, I had to add local addr field to = get the ping working.  So instead of adding “link add norm_link remote_host:4557 ALWASYON norm” as the doc suggested, I had to use = the following line “link add norm_link remote_host:4557 ALWASYON norm local_addr=3D<my local ip>”.  Not sure if anybody else = has experienced the same issue. 

 

I = am also wondering how to setup the CL for a multicast session.  I was trying to = create a multicast session by creating a multicast group with three nodes all = sharing a common NORM link to the multicast group.  Would this be possible = with the current implementation?  Or would the multicast sender need to = create a separate link per receiver to be able to perform multicast = transmission.  If it’s the latter case, I have to assume that NORM CL is solely = for transport mechanism and not as a mechanism to create multicast = session.  Is that true?  I did see the multicast_interface link option in the document.  Any example of how to setup a multicast session using = NORM CL is greatly appreciated.  Thanks.

 

Regards, =

 

Sung

 

 

 

------=_NextPart_000_001B_01C96041.F6433470-- Received: from mail-bw0-f21.google.com (mail-bw0-f21.google.com [209.85.218.21]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mBHFwi8g020486 for ; Wed, 17 Dec 2008 07:58:44 -0800 Received: by bwz14 with SMTP id 14so5717071bwz.13 for ; Wed, 17 Dec 2008 07:26:30 -0800 (PST) Received: by 10.181.210.14 with SMTP id m14mr276159bkq.163.1229527590081; Wed, 17 Dec 2008 07:26:30 -0800 (PST) Received: by 10.181.198.16 with HTTP; Wed, 17 Dec 2008 07:26:30 -0800 (PST) Message-ID: Date: Wed, 17 Dec 2008 17:26:30 +0200 From: "Shengye Lu" To: "Darren Long" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: dtn-users@mailman.dtnrg.org Subject: Re: [dtn-users] Does DTN2 survive IP address changing? X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2008 15:58:45 -0000 Hi Darren, Thank you for reply. BTW, did you try DTN reference implementation's neighbor discovery mechanism on Nokia N800? I tried to use its Bonjour implementation, but the needed Apple's mDNSResponder library can not be successfully cross-compiled in Scratchbox. I used the IP neighbor discovery as http://www.dtnrg.org/wiki/NeighborDiscovery?highlight=(discovery) , but after the IP address of DTNd changed, it could not form dynamic link with newly discovered peers - that is what I asked in my first message. Besides, it seems the IP neighbor discovery mechanism does not work in WLAN Ad-hoc mode. Cheers, Shengye On Sat, Dec 13, 2008 at 6:49 PM, Darren Long wrote: > Hi Shengye, > > When I'm using a roaming DTN node, say on my laptop, I tend to use a gateway > DTN node, with a TCP-CL interface, on my home LAN, or on a hosted virtual > root server, and have a ONDEMAND link pointing at that. > > Using a DTLSR router on all the nodes, things just seem to take care of > themselves. For connectivity between my portable nodes, a MacBook, an eee > and a Nokia N800, I use the bonjour discovery mechanism so they can find > each other over any wifi link I attach them to, and have the eee and the > N800 running the Bluetooth-CL so they find each other anyway. I can use a > Bluetooth link through to the Mac running TCP-CL if i need to. I have an > bluetooth CL interface on a node in my house too, so things hook up there > too. > > All in all, all you need is a DTN node to act as a rendevous point on the > internet, and you're well away. The DTLSR router is the key. > > Darren > > On 13 Dec 2008, at 12:39, Shengye Lu wrote: > >> Hi, >> >> I was using DTN reference implementation 2.6. My application run with >> DTNd together in one host. My application will change host's IP >> address unanticipatedly ( according to the changing network where it >> sits). I use neighbor discovery feature as >> http://www.dtnrg.org/wiki/NeighborDiscovery?highlight=(discovery) I >> use TCPCL, and I didn't use Bonjour. >> >> I think, according to the feature definition of DTN neighbor discovery >> and opportunistic contact, it should survive when the IP address of >> DTN node is changing. >> >> But in my test: >> After the DTNd node formed a dynamic link with peer, the DTNd entered >> a new network, and hence its IP address changed. >> In the new network, it received announcement from new peers. But it >> didn't build dynamic link with new peer successfully. It tend to >> insist the previously formed dynamic link. >> >> Maybe this is a bug of DTN Neighbor Discovery feature. Maybe there is >> something which we hackers can do to improve its Neighbor Discovery >> feature. >> >> Cheers, >> -- >> Shengye >> _______________________________________________ >> dtn-users mailing list >> dtn-users@maillists.intel-research.net >> http://maillists.intel-research.net/mailman/listinfo/dtn-users > > -- Shengye Received: from sink.edelkey.net (sink.edelkey.net [213.138.147.137]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mBH9xuCV003921 for ; Wed, 17 Dec 2008 01:59:57 -0800 Received: from HKISR04.ad.vtt.fi ([213.214.159.132]) by sink.edelkey.net (8.14.2/8.14.2) with ESMTP id mBH9RmGO013449; Wed, 17 Dec 2008 11:27:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C96029.B97DC8B7" Date: Wed, 17 Dec 2008 11:27:46 +0200 Message-ID: <6D08D8548E4A7B4C92AAE8527350FFDC011485A8@HKISR04.ad.vtt.fi> In-Reply-To: <66dcf31f0812161536t2a046727tf936c8910249f11f@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dtn-users] DTN simulation Thread-Index: Aclf2CBS+hbPMp2hQjmaGZIBy38/zgAUT8cg References: <66dcf31f0812161536t2a046727tf936c8910249f11f@mail.gmail.com> From: "Hautakoski Tomi" To: Subject: Re: [dtn-users] DTN simulation X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2008 09:59:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C96029.B97DC8B7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksDQoNCiANCg0KSSBhbSBub3cgc3RhcnRpbmcgbXkgcGhkIHJlbGF0ZWQgdG8gUDJQIFNvY2lh bCBhbmQgRFROLiBEb2VzIGFueW9uZSBzdWdnZXN0cyB0aGUgZ29vZCBEVE4gc2ltdWxhdGlvbiB0 b29sIHN1Y2ggdGhhdCBJIGNhbiBzaW11bGF0ZSB3aXRoIGh1bmRyZWRzIG9mIG5vZGVzIGFuZCBt b2JpbGl0eSBhcyB3ZWxsLg0KDQogDQoNCllvdSBtaWdodCB3YW50IHRvIGNoZWNrIG91dCBUS0vi gJlzIFRoZSBPTkUgc2ltdWxhdG9yIGZvciBEVE5zOg0KDQogDQoNCmh0dHA6Ly93d3cubmV0bGFi LnRray5maS90dXRraW11cy9kdG4vdGhlb25lLw0KDQogDQoNCiAgICAgICAgICArK1RvbWkNCg0K IA0KDQo= ------_=_NextPart_001_01C96029.B97DC8B7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4N CjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIg MTEgNiA5IDIgMiA0IDMgMiA0O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgMi4wY20gNzAuODVwdCAyLjBjbTt9DQpkaXYu U2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQotLT4NCjwvc3R5bGU+DQo8IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCiA8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQoNCjxib2R5 IGxhbmc9RkkgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT4NCg0KPGRpdiBjbGFzcz1TZWN0aW9uMT4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNvbnNvbGFzOw0KY29sb3I6IzFGNDk3RCc+SGksPG86cD48L286cD48L3NwYW4+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXM7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhczsNCmNvbG9y OiMxRjQ5N0QnPkkgYW0gbm93IHN0YXJ0aW5nIG15IHBoZCByZWxhdGVkIHRvIFAyUCBTb2NpYWwg YW5kIERUTi4gRG9lcw0KYW55b25lIHN1Z2dlc3RzIHRoZSBnb29kIERUTiBzaW11bGF0aW9uIHRv b2wgc3VjaCB0aGF0IEkgY2FuIHNpbXVsYXRlIHdpdGgNCmh1bmRyZWRzIG9mIG5vZGVzIGFuZCBt b2JpbGl0eSBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDb25zb2xhczsNCmNvbG9yOiMxRjQ5N0QnPllvdSBtaWdodCB3YW50IHRvIGNoZWNrIG91 dCBUS0vigJlzIFRoZSBPTkUgc2ltdWxhdG9yIGZvciBEVE5zOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KY29sb3I6IzFG NDk3RCc+PGEgaHJlZj0iaHR0cDovL3d3dy5uZXRsYWIudGtrLmZpL3R1dGtpbXVzL2R0bi90aGVv bmUvIj5odHRwOi8vd3d3Lm5ldGxhYi50a2suZmkvdHV0a2ltdXMvZHRuL3RoZW9uZS88L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhczsNCmNvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29u c29sYXM7DQpjb2xvcjojMUY0OTdEJz7CoMKgwqDCoMKgwqDCoMKgwqAgKytUb21pPG86cD48L286 cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhczsNCmNvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2Jv ZHk+DQoNCjwvaHRtbD4NCg== ------_=_NextPart_001_01C96029.B97DC8B7-- Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mBH08kZ4009699 for ; Tue, 16 Dec 2008 16:08:47 -0800 Received: by fg-out-1718.google.com with SMTP id e21so1557201fga.7 for ; Tue, 16 Dec 2008 15:36:51 -0800 (PST) Received: by 10.86.95.8 with SMTP id s8mr29696fgb.79.1229470611237; Tue, 16 Dec 2008 15:36:51 -0800 (PST) Received: by 10.86.4.10 with HTTP; Tue, 16 Dec 2008 15:36:51 -0800 (PST) Message-ID: <66dcf31f0812161536t2a046727tf936c8910249f11f@mail.gmail.com> Date: Wed, 17 Dec 2008 00:36:51 +0100 From: "Minh Nguyen" To: dtn-users@mailman.dtnrg.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_18424_16883076.1229470611235" Subject: [dtn-users] DTN simulation X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2008 00:08:47 -0000 ------=_Part_18424_16883076.1229470611235 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, I am now starting my phd related to P2P Social and DTN. Does anyone suggests the good DTN simulation tool such that I can simulate with hundreds of nodes and mobility as well. Many thanks, -Minh ------=_Part_18424_16883076.1229470611235 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all,

I am now starting my phd related to P2P Social and DTN. Does anyone suggests the good DTN simulation tool such that I can simulate with hundreds of nodes and mobility as well.

Many thanks,
-Minh
------=_Part_18424_16883076.1229470611235-- Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mBGJ3bSS028386 for ; Tue, 16 Dec 2008 11:03:37 -0800 Received: by yx-out-2324.google.com with SMTP id 3so1472459yxj.79 for ; Tue, 16 Dec 2008 10:31:47 -0800 (PST) Received: by 10.151.105.13 with SMTP id h13mr4014783ybm.197.1229452307483; Tue, 16 Dec 2008 10:31:47 -0800 (PST) Received: by 10.151.137.13 with HTTP; Tue, 16 Dec 2008 10:31:47 -0800 (PST) Message-ID: Date: Tue, 16 Dec 2008 10:31:47 -0800 From: "Bowei Du" Sender: bowei.du@gmail.com To: "Andy Scott" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4334_20305650.1229452307506" References: <4947BA43.3040603@bbn.com> <4947C198.1010503@cs.tcd.ie> <4947D3D7.1030705@cs.tcd.ie> X-Google-Sender-Auth: 2c2942f0caf3f69e Cc: dtn-users@mailman.dtnrg.org Subject: Re: [dtn-users] Windows Build? X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2008 19:03:37 -0000 ------=_Part_4334_20305650.1229452307506 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, We abandoned the Windows port about two (maybe more?) years ago. It is probably hopelessly out of date by now. It was going to be a rewrite of the Oasys core to use Windows primitives for all the operations, so not entirely trivial. Mike started porting oasys more recently over to use the Apache Runtime (apr), which, if finished, should get native Windows compatibility. If you want to get DTN to run natively on Windows, you should start there. To move to the apr-branch: $ hg update apr-branch Thanks, Bowei On Tue, Dec 16, 2008 at 9:54 AM, Andy Scott wrote: > On 16/12/2008, Stephen Farrell wrote: > > > > > > Andy Scott wrote: > > > On 16/12/2008, Stephen Farrell wrote: > > >> > > >> Christopher Small wrote: > > >> > > >> > DTN2 on Cygwin will take less effort, but still some work. > > >> > > >> > > >> Right. Check the list archive for some recent postings on cygwin. > > >> S. > > >> > > > Cool. thanks for that. > > > > > > However, I note that there were some warnings against using Cygwin, > > > lack of multicast & IPV6 feature large in my mind. > > > > > > Leaves me with two questions: > > > > > > 1. Are there similar warning for a native Win32 version? > > > > > > I don't think its been close enough to being done for so long > > that there are no warnings at all;-) > > > > > > > 2. Is there "appetite" for a native Win32 version? (not wanting too > > > sound whiney - i like doing stuff but if my time is better spent say > > > looking at the Python stuff cos no one needs/wants a Win32 variant > > > then I'll do that) > > > > > > Well, you obviously should do what you find best, but yes, if > > we had a stable Windows native version that'd be useful for at > > least our N4C project. > > > > However, I'm not sure there're any shortcuts to that target other > > than either porting DTN2 or starting from scratch, or aa you say > > trying the Python code instead. > > > > Someone had a C# partial implementation before but I forget what > > exactly they implemented, who did it, and whether they published > > their code;-) Anyone recall? > > > > So to reply to this and to Jason> > > Thanks for the replies guys. I accept that for research it is not a > "must have" but your comments regarding that it would be useful to the > project for other purposes is enough encouragement for me to keep > going :-) > > (Not an ego driven thing just my "spare" time is limited and I would > like to spend it in the best area.) > > I had thought of a re-implement into C# but as the main line was C++ I > thought an initial raw port would be beneficial. Will focus on one > area at a time :-) > > I may then be back to the list with more questions about stuff - > hopefully soon - on how to get it to work for Win32. > > Andy > -- > Brain upgrade required: a working hypothalamus > _______________________________________________ > dtn-users mailing list > dtn-users@maillists.intel-research.net > http://maillists.intel-research.net/mailman/listinfo/dtn-users > ------=_Part_4334_20305650.1229452307506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all,

We abandoned the Windows port about two (maybe more?) years ago. It is probably hopelessly out of date by now. It was going to be a rewrite of the Oasys core to use Windows primitives for all the operations, so not entirely trivial.

Mike started porting oasys more recently over to use the Apache Runtime (apr), which, if finished, should get native Windows compatibility. If you want to get DTN to run natively on Windows, you should start there.

To move to the apr-branch:

$ hg update apr-branch

Thanks,
Bowei

On Tue, Dec 16, 2008 at 9:54 AM, Andy Scott <kirkshorts@googlemail.com> wrote:
On 16/12/2008, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>
>
>  Andy Scott wrote:
>  > On 16/12/2008, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>  >>
>  >>  Christopher Small wrote:
>  >>
>  >>  > DTN2 on Cygwin will take less effort, but still some work.
>  >>
>  >>
>  >> Right. Check the list archive for some recent postings on cygwin.
>  >>  S.
>  >>
>  > Cool. thanks for that.
>  >
>  > However, I note that there were some warnings against using Cygwin,
>  > lack of multicast & IPV6 feature large in my mind.
>  >
>  > Leaves me with two questions:
>  >
>  > 1. Are there similar warning for a native Win32 version?
>
>
> I don't think its been close enough to being done for so long
>  that there are no warnings at all;-)
>
>
>  > 2. Is there "appetite" for a native Win32 version? (not wanting too
>  > sound whiney - i like doing stuff but if my time is better spent say
>  > looking at the Python stuff cos no one needs/wants a Win32 variant
>  > then I'll do that)
>
>
> Well, you obviously should do what you find best, but yes, if
>  we had a stable Windows native version that'd be useful for at
>  least our N4C project.
>
>  However, I'm not sure there're any shortcuts to that target other
>  than either porting DTN2 or starting from scratch, or aa you say
>  trying the Python code instead.
>
>  Someone had a C# partial implementation before but I forget what
>  exactly they implemented, who did it, and whether they published
>  their code;-) Anyone recall?
>

So to reply to this and to Jason>

Thanks for the replies guys. I accept that for research it is not a
"must have" but your comments regarding that it would be useful to the
project for other purposes is enough encouragement for me to keep
going :-)

(Not an ego driven thing just my "spare" time is limited and I would
like to spend it in the best area.)

I had thought of a re-implement into C# but as the main line was C++ I
thought an initial raw port would be beneficial. Will focus on one
area at a time :-)

I may then be back to the list with more questions about stuff -
hopefully soon - on how to get it to work for Win32.

Andy
--
Brain upgrade required: a working hypothalamus
_______________________________________________

------=_Part_4334_20305650.1229452307506-- Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mBGIQBrK026631 for ; Tue, 16 Dec 2008 10:26:12 -0800 Received: by yw-out-2324.google.com with SMTP id 3so1461395ywj.79 for ; Tue, 16 Dec 2008 09:54:22 -0800 (PST) Received: by 10.65.121.14 with SMTP id y14mr7591232qbm.37.1229450062466; Tue, 16 Dec 2008 09:54:22 -0800 (PST) Received: by 10.64.195.6 with HTTP; Tue, 16 Dec 2008 09:54:19 -0800 (PST) Message-ID: Date: Tue, 16 Dec 2008 17:54:19 +0000 From: "Andy Scott" To: "Stephen Farrell" In-Reply-To: <4947D3D7.1030705@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4947BA43.3040603@bbn.com> <4947C198.1010503@cs.tcd.ie> <4947D3D7.1030705@cs.tcd.ie> Cc: dtn-users@mailman.dtnrg.org Subject: Re: [dtn-users] Windows Build? X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2008 18:26:12 -0000 On 16/12/2008, Stephen Farrell wrote: > > > Andy Scott wrote: > > On 16/12/2008, Stephen Farrell wrote: > >> > >> Christopher Small wrote: > >> > >> > DTN2 on Cygwin will take less effort, but still some work. > >> > >> > >> Right. Check the list archive for some recent postings on cygwin. > >> S. > >> > > Cool. thanks for that. > > > > However, I note that there were some warnings against using Cygwin, > > lack of multicast & IPV6 feature large in my mind. > > > > Leaves me with two questions: > > > > 1. Are there similar warning for a native Win32 version? > > > I don't think its been close enough to being done for so long > that there are no warnings at all;-) > > > > 2. Is there "appetite" for a native Win32 version? (not wanting too > > sound whiney - i like doing stuff but if my time is better spent say > > looking at the Python stuff cos no one needs/wants a Win32 variant > > then I'll do that) > > > Well, you obviously should do what you find best, but yes, if > we had a stable Windows native version that'd be useful for at > least our N4C project. > > However, I'm not sure there're any shortcuts to that target other > than either porting DTN2 or starting from scratch, or aa you say > trying the Python code instead. > > Someone had a C# partial implementation before but I forget what > exactly they implemented, who did it, and whether they published > their code;-) Anyone recall? > So to reply to this and to Jason> Thanks for the replies guys. I accept that for research it is not a "must have" but your comments regarding that it would be useful to the project for other purposes is enough encouragement for me to keep going :-) (Not an ego driven thing just my "spare" time is limited and I would like to spend it in the best area.) I had thought of a re-implement into C# but as the main line was C++ I thought an initial raw port would be beneficial. Will focus on one area at a time :-) I may then be back to the list with more questions about stuff - hopefully soon - on how to get it to work for Win32. Andy -- Brain upgrade required: a working hypothalamus Received: from cs.tcd.ie (relay.cs.tcd.ie [134.226.32.56]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mBGGjPLZ022067 for ; Tue, 16 Dec 2008 08:45:25 -0800 Received: from localhost (localhost [127.0.0.1]) by relay.cs.tcd.ie (Postfix) with ESMTP id 354423EF5C; Tue, 16 Dec 2008 16:13:38 +0000 (GMT) X-Virus-Scanned: amavisd-new at cs.tcd.ie Received: from cs.tcd.ie ([127.0.0.1]) by localhost (smtp.cs.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkCu9ofA+F5B; Tue, 16 Dec 2008 16:13:37 +0000 (GMT) Received: from [134.226.62.18] (cswireless62-18.cs.tcd.ie [134.226.62.18]) by smtp.cs.tcd.ie (Postfix) with ESMTP id B2ADC3EF59; Tue, 16 Dec 2008 16:13:36 +0000 (GMT) Message-ID: <4947D3D7.1030705@cs.tcd.ie> Date: Tue, 16 Dec 2008 16:14:15 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: Andy Scott References: <4947BA43.3040603@bbn.com> <4947C198.1010503@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dtn-users@mailman.dtnrg.org Subject: Re: [dtn-users] Windows Build? X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2008 16:45:25 -0000 Andy Scott wrote: > On 16/12/2008, Stephen Farrell wrote: >> >> Christopher Small wrote: >> >> > DTN2 on Cygwin will take less effort, but still some work. >> >> >> Right. Check the list archive for some recent postings on cygwin. >> S. >> > Cool. thanks for that. > > However, I note that there were some warnings against using Cygwin, > lack of multicast & IPV6 feature large in my mind. > > Leaves me with two questions: > > 1. Are there similar warning for a native Win32 version? I don't think its been close enough to being done for so long that there are no warnings at all;-) > 2. Is there "appetite" for a native Win32 version? (not wanting too > sound whiney - i like doing stuff but if my time is better spent say > looking at the Python stuff cos no one needs/wants a Win32 variant > then I'll do that) Well, you obviously should do what you find best, but yes, if we had a stable Windows native version that'd be useful for at least our N4C project. However, I'm not sure there're any shortcuts to that target other than either porting DTN2 or starting from scratch, or aa you say trying the Python code instead. Someone had a C# partial implementation before but I forget what exactly they implemented, who did it, and whether they published their code;-) Anyone recall? Stephen. > > Again thanks for the replies. > > Andy Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mBGGhaF2021975 for ; Tue, 16 Dec 2008 08:43:36 -0800 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBGGBnf5025401 for ; Tue, 16 Dec 2008 11:11:49 -0500 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBGGBmn6025381; Tue, 16 Dec 2008 11:11:48 -0500 Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Tue, 16 Dec 2008 11:11:48 -0500 From: "Andresen, Jason R." To: Andy Scott , "dtn-users@mailman.dtnrg.org" Date: Tue, 16 Dec 2008 11:11:44 -0500 Thread-Topic: [dtn-users] Windows Build? Thread-Index: Aclfl6eqGZH37duKSRi+m/WonwaW5wAAEKRw Message-ID: <600C0C33850FFE49B76BDD81AED4D25885858865@IMCMBX3.MITRE.ORG> References: <4947BA43.3040603@bbn.com> <4947C198.1010503@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id mBGGhaF2021975 Subject: Re: [dtn-users] Windows Build? X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2008 16:43:37 -0000 From: dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users-bounces@maillists.intel-research.net] On Behalf Of Andy Scott > >1. Are there similar warning for a native Win32 version? >2. Is there "appetite" for a native Win32 version? (not wanting too >sound whiney - i like doing stuff but if my time is better spent say >looking at the Python stuff cos no one needs/wants a Win32 variant >then I'll do that) A Win32 native version of DTN2 would simplify the lives of several people and would make it a lot easier to get people interested in trying out DTN at home. From a pure research standpoint it is not necessary, but from an evangelical angle a Win32 port would be a huge win. That said, it is a big job, especially if you're trying to get it to work with Visual Studio (which is, in the long run, a preferable approach IMHO). Cygwin would be easier, but performance will always be mediocre to lousy and getting Cygwin installed is a bit of a hassle. Even if you get it to only need cygwin.dll, the versioning problems can still be a hassle. It seems like new versions of Cygwin are released all of the time. Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mBGGXSI6021526 for ; Tue, 16 Dec 2008 08:33:29 -0800 Received: by yw-out-2324.google.com with SMTP id 3so1431795ywj.79 for ; Tue, 16 Dec 2008 08:01:41 -0800 (PST) Received: by 10.64.88.13 with SMTP id l13mr7488334qbb.83.1229443300831; Tue, 16 Dec 2008 08:01:40 -0800 (PST) Received: by 10.64.195.6 with HTTP; Tue, 16 Dec 2008 08:01:40 -0800 (PST) Message-ID: Date: Tue, 16 Dec 2008 16:01:40 +0000 From: "Andy Scott" To: dtn-users@mailman.dtnrg.org In-Reply-To: <4947C198.1010503@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4947BA43.3040603@bbn.com> <4947C198.1010503@cs.tcd.ie> Subject: Re: [dtn-users] Windows Build? X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2008 16:33:29 -0000 On 16/12/2008, Stephen Farrell wrote: > > > Christopher Small wrote: > > > DTN2 on Cygwin will take less effort, but still some work. > > > Right. Check the list archive for some recent postings on cygwin. > S. > Cool. thanks for that. However, I note that there were some warnings against using Cygwin, lack of multicast & IPV6 feature large in my mind. Leaves me with two questions: 1. Are there similar warning for a native Win32 version? 2. Is there "appetite" for a native Win32 version? (not wanting too sound whiney - i like doing stuff but if my time is better spent say looking at the Python stuff cos no one needs/wants a Win32 variant then I'll do that) Again thanks for the replies. Andy -- Brain upgrade required: a working hypothalamus Received: from mail-gx0-f12.google.com (mail-gx0-f12.google.com [209.85.217.12]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mBGFUnP0018629 for ; Tue, 16 Dec 2008 07:30:50 -0800 Received: by gxk5 with SMTP id 5so2407314gxk.13 for ; Tue, 16 Dec 2008 06:59:04 -0800 (PST) Received: by 10.65.158.19 with SMTP id k19mr7459389qbo.14.1229439543660; Tue, 16 Dec 2008 06:59:03 -0800 (PST) Received: by 10.64.195.6 with HTTP; Tue, 16 Dec 2008 06:59:03 -0800 (PST) Message-ID: Date: Tue, 16 Dec 2008 14:59:03 +0000 From: "Andy Scott" To: dtn-users@mailman.dtnrg.org In-Reply-To: <4947BA43.3040603@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4947BA43.3040603@bbn.com> Subject: Re: [dtn-users] Windows Build? X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2008 15:30:50 -0000 On 16/12/2008, Christopher Small wrote: > The code hasn't compiled on Windows for a long time, nobody has been > tracking it. Bowei Du worked on it for a while more than a year ago, and > as far as I know he never finished hacking it into shape. > > DTN2 on Cygwin will take less effort, but still some work. > > - Chris Thanks for that - that would explain the username comments and why it is very Linux/GCC centric in many places. I'll try to continue on with it then. I will see how far I can get with it. Andy -- Brain upgrade required: a working hypothalamus Received: from cs.tcd.ie (relay.cs.tcd.ie [134.226.32.56]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mBGFRYwP018461 for ; Tue, 16 Dec 2008 07:27:35 -0800 Received: from localhost (localhost [127.0.0.1]) by relay.cs.tcd.ie (Postfix) with ESMTP id 39BA13EF4E; Tue, 16 Dec 2008 14:55:48 +0000 (GMT) X-Virus-Scanned: amavisd-new at cs.tcd.ie Received: from cs.tcd.ie ([127.0.0.1]) by localhost (smtp.cs.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQ7F-l7fVaIj; Tue, 16 Dec 2008 14:55:47 +0000 (GMT) Received: from [134.226.62.18] (cswireless62-18.cs.tcd.ie [134.226.62.18]) by smtp.cs.tcd.ie (Postfix) with ESMTP id BCC0E3EF40; Tue, 16 Dec 2008 14:55:46 +0000 (GMT) Message-ID: <4947C198.1010503@cs.tcd.ie> Date: Tue, 16 Dec 2008 14:56:24 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: Christopher Small References: <4947BA43.3040603@bbn.com> In-Reply-To: <4947BA43.3040603@bbn.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dtn-users@mailman.dtnrg.org Subject: Re: [dtn-users] Windows Build? X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2008 15:27:35 -0000 Christopher Small wrote: > DTN2 on Cygwin will take less effort, but still some work. Right. Check the list archive for some recent postings on cygwin. S. > > - Chris > Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mBGEur91017109 for ; Tue, 16 Dec 2008 06:56:53 -0800 Received: from sneetch.bbn.com ([128.89.80.78]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LCarD-0007mw-F2; Tue, 16 Dec 2008 09:25:07 -0500 Message-ID: <4947BA43.3040603@bbn.com> Date: Tue, 16 Dec 2008 09:25:07 -0500 From: Christopher Small User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Andy Scott References: In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6F6F97BB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dtn-users@mailman.dtnrg.org Subject: Re: [dtn-users] Windows Build? X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2008 14:56:53 -0000 The code hasn't compiled on Windows for a long time, nobody has been tracking it. Bowei Du worked on it for a while more than a year ago, and as far as I know he never finished hacking it into shape. DTN2 on Cygwin will take less effort, but still some work. - Chris -- Dr. Christopher Small 617.873.6261 (vox) Networking Research 617.873.6091 (fax) BBN Technologies | MS 6/5C | 10 Moulton St | Cambridge MA, 02138 Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mBGBcRN2007608 for ; Tue, 16 Dec 2008 03:38:28 -0800 Received: by yx-out-2324.google.com with SMTP id 3so1382729yxj.79 for ; Tue, 16 Dec 2008 03:06:46 -0800 (PST) Received: by 10.65.240.16 with SMTP id s16mr7226771qbr.59.1229425605959; Tue, 16 Dec 2008 03:06:45 -0800 (PST) Received: by 10.64.195.6 with HTTP; Tue, 16 Dec 2008 03:06:45 -0800 (PST) Message-ID: Date: Tue, 16 Dec 2008 11:06:45 +0000 From: "Andy Scott" To: dtn-users@mailman.dtnrg.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [dtn-users] Windows Build? X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2008 11:38:28 -0000 Hi All I was wondering if there was an official port of the code to native Windows? I have taken the source from the mercurial repository using the commands listed on the site ( http://www.dtnrg.org/wiki/Code ) and am attempting to get it to compile for VisualStudio 2005 (a bit old school now that 2008 is out but still a good base). Progress so far: - I started compiling the Oasys library first. I have been using the Makefile.win32 & Sources.mk to guide what files I require. - There are multiple errors, both compiler and platform specific that I have "worked" round by hacking large swathes of functionality out. Though of course this lack of functionality will come back to bit me if I progress further. I have to admit to now being a little down about the scope of the task to get this stuff to even build - which is a big downer for me as I really like playing with network stuff. I am not using Makefile.win32 directly but instead am using the IDE (with a project/solution I have created) - if this is the source of my woes then I'll stop using it and got to the command line. [PS - I have tried to get it to compile under Cygwin; however, the configure fails there as it looks for a kernel header file that defines xdr_init (Sun RPC afaik) which of course it doesn't find. So again as an "out of the box" thing its a bust too] Andy -- Brain upgrade required: a working hypothalamus Received: from asmtpout020.mac.com (asmtpout020.mac.com [17.148.16.95]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mBDHJvSo026835 for ; Sat, 13 Dec 2008 09:19:57 -0800 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.0.3] (78-33-82-89.static.enta.net [78.33.82.89]) by asmtp020.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KBT000N7QQECW20@asmtp020.mac.com> for dtn-users@mailman.dtnrg.org; Sat, 13 Dec 2008 08:49:29 -0800 (PST) Message-id: From: Darren Long To: Shengye Lu In-reply-to: Date: Sat, 13 Dec 2008 16:49:24 +0000 References: X-Mailer: Apple Mail (2.929.2) Cc: dtn-users@mailman.dtnrg.org Subject: Re: [dtn-users] Does DTN2 survive IP address changing? X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2008 17:19:57 -0000 Hi Shengye, When I'm using a roaming DTN node, say on my laptop, I tend to use a gateway DTN node, with a TCP-CL interface, on my home LAN, or on a hosted virtual root server, and have a ONDEMAND link pointing at that. Using a DTLSR router on all the nodes, things just seem to take care of themselves. For connectivity between my portable nodes, a MacBook, an eee and a Nokia N800, I use the bonjour discovery mechanism so they can find each other over any wifi link I attach them to, and have the eee and the N800 running the Bluetooth-CL so they find each other anyway. I can use a Bluetooth link through to the Mac running TCP-CL if i need to. I have an bluetooth CL interface on a node in my house too, so things hook up there too. All in all, all you need is a DTN node to act as a rendevous point on the internet, and you're well away. The DTLSR router is the key. Darren On 13 Dec 2008, at 12:39, Shengye Lu wrote: > Hi, > > I was using DTN reference implementation 2.6. My application run with > DTNd together in one host. My application will change host's IP > address unanticipatedly ( according to the changing network where it > sits). I use neighbor discovery feature as > http://www.dtnrg.org/wiki/NeighborDiscovery?highlight=(discovery) I > use TCPCL, and I didn't use Bonjour. > > I think, according to the feature definition of DTN neighbor discovery > and opportunistic contact, it should survive when the IP address of > DTN node is changing. > > But in my test: > After the DTNd node formed a dynamic link with peer, the DTNd entered > a new network, and hence its IP address changed. > In the new network, it received announcement from new peers. But it > didn't build dynamic link with new peer successfully. It tend to > insist the previously formed dynamic link. > > Maybe this is a bug of DTN Neighbor Discovery feature. Maybe there is > something which we hackers can do to improve its Neighbor Discovery > feature. > > Cheers, > -- > Shengye > _______________________________________________ > dtn-users mailing list > dtn-users@maillists.intel-research.net > http://maillists.intel-research.net/mailman/listinfo/dtn-users Received: from mail-bw0-f13.google.com (mail-bw0-f13.google.com [209.85.218.13]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mBDDAOPb015599 for ; Sat, 13 Dec 2008 05:10:25 -0800 Received: by bwz6 with SMTP id 6so4393716bwz.13 for ; Sat, 13 Dec 2008 04:40:00 -0800 (PST) Received: by 10.181.153.12 with SMTP id f12mr1687809bko.132.1229172000225; Sat, 13 Dec 2008 04:40:00 -0800 (PST) Received: by 10.181.218.16 with HTTP; Sat, 13 Dec 2008 04:39:59 -0800 (PST) Message-ID: Date: Sat, 13 Dec 2008 14:39:59 +0200 From: "Shengye Lu" To: dtn-users@mailman.dtnrg.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [dtn-users] Does DTN2 survive IP address changing? X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2008 13:10:25 -0000 Hi, I was using DTN reference implementation 2.6. My application run with DTNd together in one host. My application will change host's IP address unanticipatedly ( according to the changing network where it sits). I use neighbor discovery feature as http://www.dtnrg.org/wiki/NeighborDiscovery?highlight=(discovery) I use TCPCL, and I didn't use Bonjour. I think, according to the feature definition of DTN neighbor discovery and opportunistic contact, it should survive when the IP address of DTN node is changing. But in my test: After the DTNd node formed a dynamic link with peer, the DTNd entered a new network, and hence its IP address changed. In the new network, it received announcement from new peers. But it didn't build dynamic link with new peer successfully. It tend to insist the previously formed dynamic link. Maybe this is a bug of DTN Neighbor Discovery feature. Maybe there is something which we hackers can do to improve its Neighbor Discovery feature. Cheers, -- Shengye Received: from IE1EHSOBE001.bigfish.com (outbound-dub.frontbridge.com [213.199.154.16]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mBADShfS013812; Wed, 10 Dec 2008 05:28:43 -0800 Received: from mail172-dub-R.bigfish.com (10.5.252.3) by IE1EHSOBE001.bigfish.com (10.5.252.21) with Microsoft SMTP Server id 8.1.291.1; Wed, 10 Dec 2008 12:59:39 +0000 Received: from mail172-dub (localhost.localdomain [127.0.0.1]) by mail172-dub-R.bigfish.com (Postfix) with ESMTP id 69E0CA48116; Wed, 10 Dec 2008 12:59:38 +0000 (UTC) X-BigFish: VPS-13(zz1454M1432R98dR1805M103dKzzzzz2dh6bh87il61h) X-Spam-TCS-SCL: 0:0 X-FB-DOMAIN-IP-MATCH: fail Received: by mail172-dub (MessageSwitch) id 1228913975481228_5036; Wed, 10 Dec 2008 12:59:35 +0000 (UCT) Received: from imx1.tcd.ie (imx1.tcd.ie [134.226.17.160]) by mail172-dub.bigfish.com (Postfix) with ESMTP id 29A6F13806D; Wed, 10 Dec 2008 12:59:35 +0000 (UTC) Received: from Vams.imx1 (imx1.tcd.ie [134.226.17.160]) by imx1.tcd.ie (Postfix) with SMTP id EC3FE4938; Wed, 10 Dec 2008 12:59:34 +0000 (GMT) Received: from imx1.tcd.ie ([134.226.17.160]) by imx1 ([127.0.0.1]) with SMTP (gateway) id A06369E6F84; Wed, 10 Dec 2008 12:59:34 +0000 Received: from [134.226.62.18] (cswireless62-18.cs.tcd.ie [134.226.62.18]) by imx1.tcd.ie (Postfix) with ESMTP id BB0DA4946; Wed, 10 Dec 2008 12:59:34 +0000 (GMT) Message-ID: <493FBD4E.4060605@cs.tcd.ie> Date: Wed, 10 Dec 2008 12:59:58 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: Kurtis Heimerl References: <9a4753250812091547q6b1afe92lbbb908d3b86dae2a@mail.gmail.com> In-Reply-To: <9a4753250812091547q6b1afe92lbbb908d3b86dae2a@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A16369E6F84 X-AntiVirus-Status: Host: imx1.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.60.2 VDF=10.95.2) Cc: dtn-users@maillists.intel-research.net, dtn-interest@maillists.intel-research.net Subject: Re: [dtn-users] [dtn-interest] pydtn alpha released X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 13:28:43 -0000 Excellent! Be interested to see how folks put this to use. Now that we've got even more implementations, does anyone (with an a/c) feel like doing an update to the "Code" page on the wiki? [1] I'll put it on my to-do list but it'll be (at least) a few days before I get to it. Stephen. [1] http://www.dtnrg.org/wiki/Code Kurtis Heimerl wrote: > The alpha version of the pure python dtn implementation has been released. > > It's available by doing the following: > hg clone http://dtn.sourceforge.net/hg/pydtn > > It has been tested to interoperate with the DTN 2.6 reference > implementation, sending and receiving bundles of arbitrary size over > the tcpcl. However, it has not been extensively tested, and there are > no doubt many bugs. Feel free to find those for me! Also, as it's > alpha software, it's not a terribly elegant implementation in places. > I hope to remedy that in time. > > My current work is to port this to the pys60 environment on the > Symbian operating system. > > Thanks! > _______________________________________________ > dtn-interest mailing list > dtn-interest@maillists.intel-research.net > http://maillists.intel-research.net/mailman/listinfo/dtn-interest > Received: from yw-out-1718.google.com (yw-out-1718.google.com [74.125.46.158]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mBA0MBCf010460 for ; Tue, 9 Dec 2008 16:22:11 -0800 Received: by yw-out-1718.google.com with SMTP id 5so110227ywm.34 for ; Tue, 09 Dec 2008 15:53:22 -0800 (PST) Received: by 10.90.120.17 with SMTP id s17mr522322agc.101.1228866801314; Tue, 09 Dec 2008 15:53:21 -0800 (PST) Received: by 10.90.79.18 with HTTP; Tue, 9 Dec 2008 15:53:21 -0800 (PST) Message-ID: <9a4753250812091553v585eda88qaed9677605663516@mail.gmail.com> Date: Tue, 9 Dec 2008 15:53:21 -0800 From: "Kurtis Heimerl" Sender: munncha@gmail.com To: dtn-users@maillists.intel-research.net In-Reply-To: <9a4753250812091547q6b1afe92lbbb908d3b86dae2a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9a4753250812091547q6b1afe92lbbb908d3b86dae2a@mail.gmail.com> X-Google-Sender-Auth: adca9e5adde7a6d8 Subject: [dtn-users] pydtn alpha released X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2008 00:22:12 -0000 The alpha version of the pure python dtn implementation has been released. It's available by doing the following: hg clone http://dtn.sourceforge.net/hg/pydtn It has been tested to interoperate with the DTN 2.6 reference implementation, sending and receiving bundles of arbitrary size over the tcpcl. However, it has not been extensively tested, and there are no doubt many bugs. Feel free to find those for me! Also, as it's alpha software, it's not a terribly elegant implementation in places. I hope to remedy that in time. My current work is to port this to the pys60 environment on the Symbian operating system. Thanks! Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mB9FAKGQ018028 for ; Tue, 9 Dec 2008 07:10:21 -0800 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mB9Eff84013721 for ; Tue, 9 Dec 2008 09:41:41 -0500 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mB9Efep7013702; Tue, 9 Dec 2008 09:41:40 -0500 Received: from IMCMBX4.MITRE.ORG ([129.83.29.207]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Tue, 9 Dec 2008 09:41:40 -0500 From: "Bush, Jeff" To: Darren Long , dtn-users mailing list Date: Tue, 9 Dec 2008 09:41:39 -0500 Thread-Topic: [dtn-users] DTN2 with NORM Thread-Index: AclZf2osC0un2UroSHOrydHqrJ4FgAAiwxPg Message-ID: <29705F5F232FBC4C96D1CAE867538F0B0A6F06DE5D@IMCMBX4.MITRE.ORG> References: <615B3901F7E97940A46DF9A53BB5D4BAFDC835@IMCSRV7.MITRE.ORG> <4939A580.20506@gaia.arc.nasa.gov> <51C497E0-C933-4FBB-B138-DEBD815DFD56@mac.com> <29705F5F232FBC4C96D1CAE867538F0B0A6F06DAC0@IMCMBX4.MITRE.ORG> <3F9D5C4C-928D-4B43-8FCE-6FF73E641BA9@mac.com> In-Reply-To: <3F9D5C4C-928D-4B43-8FCE-6FF73E641BA9@mac.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01C959E2.53B76A60" MIME-Version: 1.0 Subject: Re: [dtn-users] DTN2 with NORM X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 15:10:21 -0000 ------=_NextPart_000_0000_01C959E2.53B76A60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >On a more mundane matter, I note that norm_conv_layer.txt refers to >the "keepalive_interval" option, but having failed to get dtnd to >recognise it earlier today, I've now found that it is actually >"keepalive_intvl" in the code - perhaps you could remove the 3 >redundant bytes from the .txt file, or move them to the source ;-) Thanks, I updated to the txt file to read keepalive_intvl. >Hope you don't mind us jumping on your band-wagon so quickly, but it's >a very interesting CL. I appreciate any time you and others can spend exercising the norm cl code. Comments or suggestions for improvement are welcome. -Jeff ------=_NextPart_000_0000_01C959E2.53B76A60 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKtTCCA2Ew ggJJoAMCAQICAhwzMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMDgwNjI3MjA0NTEyWhcNMDkxMjE5MjA0NTEyWjBWMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEVMBMGCgmSJomT8ixkAQETBWpidXNoMRgwFgYDVQQDEw9C dXNoIEplZmZyZXkgRC4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKIAhldyfonlF/aWaHLg Fqhw1QV2YBkox11Fw98vgjGvJTfsdwwSnP6mxH5HLiDAcpv3FTTQnC2SB/YxeAegPoqIktceA2Ww 2acTpQLp1DHulcxtnEG3pmv6AwpGO77hUcVVF2lC7czF5j9t/m3H9hnYxmqcBx77JGyES060+7MZ AgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQWBBTLCLnhPmFRXByDup1S/jysjuv4 VzAfBgNVHSMEGDAWgBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRw Oi8vd3d3Lm1pdHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwGgYDVR0RBBMw EYEPamJ1c2hAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAoqGuAriAsuQmR98gd5/VVc15H D579SdtvzosVljwgZXX9FI/aniCw1rt7cryWIVbblk5gteOPWiUAR2XVA0M+FLA0TWOz9bDxJZlh CJ/tGTXIMrnlO5Ea2cTTviNH4s9uvNwp53u//U3pcuciVW5xPS+Y8vlB87oSkHI73uJYk2nfzNUB /kvMj8oLVkElyBWAUvdvG+B4aJL6WVoI3OJAQjx9UnSWDooqSVIhc9kdDRzx4Kt6IsXqwYWmj1OZ qQaYmJY3b2s45zd/rBlFjIyVpyyi2G3xhgQTlubDg5QiSCJQrpqA/G8cbydsNBquRM3o/0QyQgML vn5N4D905dzlMIIDZDCCAkygAwIBAgIBATANBgkqhkiG9w0BAQUFADBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEkMCIGA1UEAxMbTUlUUkUgQ29y cG9yYXRpb24gUm9vdCBDQS0xMB4XDTA2MDYwMTA0MDAwMFoXDTE4MDYwMTA0MDAwMFowWjESMBAG A1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJDAiBgNVBAMT G01JVFJFIENvcnBvcmF0aW9uIFJvb3QgQ0EtMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAK9rWpY9mIQm/m8y0JuO3RxO7Q1ufXlDVwqpAFcqLxVIf3Nk+Y/F9aLMknslKoUnn+wtTPc2 ydRWOktgF0VzE1ec4uNe2YM8U57CblP3w1lz3BFEKIPO3h/yqwcUjX1KE+Irdw3lSq0l/6LrpBUs DVLoI0vqjZ4YCwCXlafHA6HYF9xZTl82UcNVz0ooCUMNakeMLYsscBRss/hnMwgkpwuAsoUy2AzY AR9pIfOaLtZR1QdEK0JuWsXurM+zL+MEsWuvxVxf6Zvuxqr3mkQ6KWByLHT+dpbuQl8zmmHtQEH5 LU786Ef5mNDgyNafATwD9gOtDHU5UsA6Lb0GyGj+XyUCAwEAAaM1MDMwEgYDVR0TAQH/BAgwBgEB /wIBAzAdBgNVHQ4EFgQUx3BRANhN/uQB1GiWxT2fmpf+dC8wDQYJKoZIhvcNAQEFBQADggEBABr5 9V8KWOKYGVx9bCR8le5c0pa6f3GWgUqOerpI8aAAgqLktQOKXrRrQ1o0agZI7cjXHNi3udxrKHbW pe6VxVMMWq5tIl2/nVodO4lhxhRfvYs3+BKrTdRUsEInNibtktSWRvZgujvFR5ndygsVxPkAdHfq SMbhxgepeAfSWIGXyPGk3SDCBpyLiyA8tSPXDi3zOgof7PEYXBfBM/8/561CqIlnlPTR8submTP2 aafHGaYi9QY12wICEaF2cXbilytHjcs2DI4En0M9QcE2reRRBE7jxYErEHF+U60rOwgLH8cS0gAF xmft14AMdxj2ylQtl8GdBh0SnLPm2CHtjaowggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUA MFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcNMTIw NjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPnhlflKPFPMXGG+iqG pImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI7fnUWiUasNP2ING19aAf rQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407K1i+7WnrRsMVKhICfgmiO/Xi VR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClHDtPJs7UOTjMYBS2fTzztC+wwOTp6 +A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQAB o4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYDVR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9I jWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAWgBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8E QTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1pdHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRy ZV9vcmcuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IA e7u60LK0V9jVZ9E2a+c0MZiSojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8 WDPzlud/WQAzkjrU2nuh8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680 ukiJ9yF6UmEXuciB77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXt p3DIrVqE/DZr146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7Nqg MYICvTCCArkCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRl IEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIcMzAJ BgUrDgMCGgUAoIIBsDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w ODEyMDkxNDQxMzVaMCMGCSqGSIb3DQEJBDEWBBSQn+NUE5QqOmpct/qDqjdT+fnHcDBnBgkqhkiG 9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTByBgkrBgEEAYI3EAQxZTBj MF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScw JQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAhwzMHQGCyqGSIb3DQEJEAIL MWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIcMzANBgkqhkiG9w0B AQEFAASBgBPsfloH2Tv/qF8Ymk5nyWO5fDgwHpD8s6EQbPUWWrzym4PRd1JQxkbJ8SqGeBFisxCt NExwsXbWzh4+CrintZMlFdFFURpzjMwOOkEuOJvviSZ8xoo3h9dBy/GEdJIfAjca69mDsXVvWOwn V+4RV/s1w//Us11j7Hun3vi+djwOAAAAAAAA ------=_NextPart_000_0000_01C959E2.53B76A60-- Received: from asmtpout017.mac.com (asmtpout017.mac.com [17.148.16.92]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mB8MLXgJ004417 for ; Mon, 8 Dec 2008 14:21:33 -0800 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.0.3] (78-33-82-89.static.enta.net [78.33.82.89]) by asmtp017.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KBK00I6TVGMWV00@asmtp017.mac.com> for dtn-users@mailman.dtnrg.org; Mon, 08 Dec 2008 13:53:12 -0800 (PST) Message-id: <3F9D5C4C-928D-4B43-8FCE-6FF73E641BA9@mac.com> From: Darren Long To: dtn-users mailing list In-reply-to: <29705F5F232FBC4C96D1CAE867538F0B0A6F06DAC0@IMCMBX4.MITRE.ORG> Date: Mon, 08 Dec 2008 21:53:10 +0000 References: <615B3901F7E97940A46DF9A53BB5D4BAFDC835@IMCSRV7.MITRE.ORG> <4939A580.20506@gaia.arc.nasa.gov> <51C497E0-C933-4FBB-B138-DEBD815DFD56@mac.com> <29705F5F232FBC4C96D1CAE867538F0B0A6F06DAC0@IMCMBX4.MITRE.ORG> X-Mailer: Apple Mail (2.929.2) Subject: Re: [dtn-users] DTN2 with NORM X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 22:21:33 -0000 Thanks Jeff, this seems to have done the trick. I had similar problems building on Red Hat EL4 today, but this should cover it. On a more mundane matter, I note that norm_conv_layer.txt refers to the "keepalive_interval" option, but having failed to get dtnd to recognise it earlier today, I've now found that it is actually "keepalive_intvl" in the code - perhaps you could remove the 3 redundant bytes from the .txt file, or move them to the source ;-) Hope you don't mind us jumping on your band-wagon so quickly, but it's a very interesting CL. Cheers, Darren Received: from vishnu.arc.nasa.gov (vishnu.arc.nasa.gov [143.232.155.60]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mB8Kdgwq032248 for ; Mon, 8 Dec 2008 12:39:42 -0800 Received: from vishnu.arc.nasa.gov (localhost [127.0.0.1]) by vishnu.arc.nasa.gov (Postfix) with ESMTP id 82A41446DC7; Mon, 8 Dec 2008 12:11:23 -0800 (PST) Message-ID: <493D7F6B.5080906@gaia.arc.nasa.gov> Date: Mon, 08 Dec 2008 12:11:23 -0800 From: Don Sullivan User-Agent: Thunderbird 2.0.0.18pre (Macintosh/20081101) MIME-Version: 1.0 To: "Bush, Jeff" References: <615B3901F7E97940A46DF9A53BB5D4BAFDC835@IMCSRV7.MITRE.ORG> <4939A580.20506@gaia.arc.nasa.gov> <51C497E0-C933-4FBB-B138-DEBD815DFD56@mac.com> <29705F5F232FBC4C96D1CAE867538F0B0A6F06DAC0@IMCMBX4.MITRE.ORG> In-Reply-To: <29705F5F232FBC4C96D1CAE867538F0B0A6F06DAC0@IMCMBX4.MITRE.ORG> Content-Type: multipart/mixed; boundary="------------090706090703060702070305" Cc: dtn-users mailing list Subject: Re: [dtn-users] DTN2 with NORM, build problem on OSX X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 20:39:42 -0000 This is a multi-part message in MIME format. --------------090706090703060702070305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jeff, Builds swimmingly now - THANK YOU. (Well, builds after manually adding -lresolv to work around the silly Apple res_9_init thingie: added after SYS_EXTLIB_LDFLAGS ... -ldb-4.6 in System.make. I'm certain this is NOT the right way to do it, but my Config* mojo rating is WAY low ...) Thanks again, Don Now for some REAL work ... Bush, Jeff wrote: > Hopefully the bug fixes I just committed will solve these issues. > > Thanks for testing the code! > > >> -----Original Message----- >> From: dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users- >> bounces@maillists.intel-research.net] On Behalf Of Darren Long >> Sent: Saturday, December 06, 2008 6:03 AM >> To: dtn-users mailing list >> Subject: Re: [dtn-users] DTN2 with NORM, build problem on OSX >> >> As a quick hack, I made NORMReceiver::process_data() public and added >> some casts, and now have a NORM link up between my eee (running Ubuntu- >> eee) and the MacBook Pro, and carrying bundles. >> >> Good stuff! >> >> Some more experimenting with this, then back to getting ION to talk to >> a dtnd ;-) >> >> Darren >> >> >> On 5 Dec 2008, at 22:04, Don Sullivan wrote: >> >> >>> I'm getting the following errors building DTN2 with NORM support: >>> >>> conv_layers/NORMReceiver.cc: In member function 'virtual void >>> dtn::ReceiveWatermark::run(dtn::NORMReceiver*)': >>> conv_layers/NORMReceiver.cc:269: warning: format '%i' expects type >>> 'int', but argument 4 has type 'size_t' >>> conv_layers/NORMReceiver.cc:341: error: invalid conversion from >>> 'size_t*' to 'unsigned int*' >>> conv_layers/NORMReceiver.cc:341: error: initializing argument 3 of >>> 'bool NormNodeGetCommand(const void*, char*, unsigned int*)' >>> conv_layers/NORMReceiver.cc: In member function 'bool >>> dtn::ReceiveWatermark::BundleReassemblyBuf::check_completes(bool)': >>> conv_layers/NORMReceiver.cc:134: error: 'void >>> dtn::NORMReceiver::process_data(u_char*, size_t)' is protected >>> conv_layers/NORMReceiver.cc:543: error: within this context >>> conv_layers/NORMReceiver.cc:134: error: 'void >>> dtn::NORMReceiver::process_data(u_char*, size_t)' is protected >>> conv_layers/NORMReceiver.cc:546: error: within this context >>> >>> Help, please... >>> >>> Thanks, >>> Don >>> >>> oasys-1.3.0 with xerces-c and bdb4.6 >>> NORM Version 1.4b4, with DTN2 patch >>> DTN2 2.6.0 from mercurial >>> gcc-4.0.1 i686-apple-darwin9 >>> Darwin Kernel Version 9.5.0 (10.5.5) >>> >>> -- >>> --------------------------------------------- >>> Don Sullivan >>> NASA Ames Research Center >>> MS 242-4 >>> Moffett Field, CA 94035-1000 >>> Office: 650 604 0526 >>> Mobile: 650 714 9742 >>> email: donald.v.sullivan@nasa.gov >>> OR: yes_its_don@mac.com >>> --------------------------------------------- >>> Better Die Standing, Than Live Kneeling >>> - Sic gorgiamus allos subjectatos nunc >>> >>> _______________________________________________ >>> dtn-users mailing list >>> dtn-users@maillists.intel-research.net >>> http://maillists.intel-research.net/mailman/listinfo/dtn-users >>> >> _______________________________________________ >> dtn-users mailing list >> dtn-users@maillists.intel-research.net >> http://maillists.intel-research.net/mailman/listinfo/dtn-users >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> dtn-users mailing list >> dtn-users@maillists.intel-research.net >> http://maillists.intel-research.net/mailman/listinfo/dtn-users >> -- --------------------------------------------- Don Sullivan NASA Ames Research Center MS 242-4 Moffett Field, CA 94035-1000 Office: 650 604 0526 Mobile: 650 714 9742 email: donald.v.sullivan@nasa.gov OR: yes_its_don@mac.com --------------------------------------------- Better Die Standing, Than Live Kneeling - Sic gorgiamus allos subjectatos nunc --------------090706090703060702070305 Content-Type: text/x-vcard; charset=utf-8; name="dsullivan.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dsullivan.vcf" begin:vcard fn:Don Sullivan n:Sullivan;Don org:NASA Ames Research Center;Biospheric Science, Science Directorate adr:;;MS 242-4;Moffett Field;CA;94035;USA email;internet:donald.v.sullivan@nasa.gov title:Computer Jockey/Sr Engineer tel;work:+1 650 604 0526 tel;cell:+1 650 714 9742 version:2.1 end:vcard --------------090706090703060702070305-- Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mB8HaYrj023984 for ; Mon, 8 Dec 2008 09:36:34 -0800 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mB8H8IMm031529 for ; Mon, 8 Dec 2008 12:08:18 -0500 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mB8H8H99031499; Mon, 8 Dec 2008 12:08:17 -0500 Received: from IMCMBX4.MITRE.ORG ([129.83.29.207]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Mon, 8 Dec 2008 12:08:17 -0500 From: "Bush, Jeff" To: Darren Long , dtn-users mailing list Date: Mon, 8 Dec 2008 12:08:16 -0500 Thread-Topic: [dtn-users] DTN2 with NORM, build problem on OSX Thread-Index: AclXkmBpC6p5S+39RTCplzXi1udJ5QBxFbdw Message-ID: <29705F5F232FBC4C96D1CAE867538F0B0A6F06DAC0@IMCMBX4.MITRE.ORG> References: <615B3901F7E97940A46DF9A53BB5D4BAFDC835@IMCSRV7.MITRE.ORG> <4939A580.20506@gaia.arc.nasa.gov> <51C497E0-C933-4FBB-B138-DEBD815DFD56@mac.com> In-Reply-To: <51C497E0-C933-4FBB-B138-DEBD815DFD56@mac.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0016_01C9592D.A71B62C0" MIME-Version: 1.0 Subject: Re: [dtn-users] DTN2 with NORM, build problem on OSX X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2008 17:36:35 -0000 ------=_NextPart_000_0016_01C9592D.A71B62C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hopefully the bug fixes I just committed will solve these issues. Thanks for testing the code! >-----Original Message----- >From: dtn-users-bounces@maillists.intel-research.net [mailto:dtn-users- >bounces@maillists.intel-research.net] On Behalf Of Darren Long >Sent: Saturday, December 06, 2008 6:03 AM >To: dtn-users mailing list >Subject: Re: [dtn-users] DTN2 with NORM, build problem on OSX > >As a quick hack, I made NORMReceiver::process_data() public and added >some casts, and now have a NORM link up between my eee (running Ubuntu- >eee) and the MacBook Pro, and carrying bundles. > >Good stuff! > >Some more experimenting with this, then back to getting ION to talk to >a dtnd ;-) > >Darren > > >On 5 Dec 2008, at 22:04, Don Sullivan wrote: > >> >> I'm getting the following errors building DTN2 with NORM support: >> >> conv_layers/NORMReceiver.cc: In member function 'virtual void >> dtn::ReceiveWatermark::run(dtn::NORMReceiver*)': >> conv_layers/NORMReceiver.cc:269: warning: format '%i' expects type >> 'int', but argument 4 has type 'size_t' >> conv_layers/NORMReceiver.cc:341: error: invalid conversion from >> 'size_t*' to 'unsigned int*' >> conv_layers/NORMReceiver.cc:341: error: initializing argument 3 of >> 'bool NormNodeGetCommand(const void*, char*, unsigned int*)' >> conv_layers/NORMReceiver.cc: In member function 'bool >> dtn::ReceiveWatermark::BundleReassemblyBuf::check_completes(bool)': >> conv_layers/NORMReceiver.cc:134: error: 'void >> dtn::NORMReceiver::process_data(u_char*, size_t)' is protected >> conv_layers/NORMReceiver.cc:543: error: within this context >> conv_layers/NORMReceiver.cc:134: error: 'void >> dtn::NORMReceiver::process_data(u_char*, size_t)' is protected >> conv_layers/NORMReceiver.cc:546: error: within this context >> >> Help, please... >> >> Thanks, >> Don >> >> oasys-1.3.0 with xerces-c and bdb4.6 >> NORM Version 1.4b4, with DTN2 patch >> DTN2 2.6.0 from mercurial >> gcc-4.0.1 i686-apple-darwin9 >> Darwin Kernel Version 9.5.0 (10.5.5) >> >> -- >> --------------------------------------------- >> Don Sullivan >> NASA Ames Research Center >> MS 242-4 >> Moffett Field, CA 94035-1000 >> Office: 650 604 0526 >> Mobile: 650 714 9742 >> email: donald.v.sullivan@nasa.gov >> OR: yes_its_don@mac.com >> --------------------------------------------- >> Better Die Standing, Than Live Kneeling >> - Sic gorgiamus allos subjectatos nunc >> >> _______________________________________________ >> dtn-users mailing list >> dtn-users@maillists.intel-research.net >> http://maillists.intel-research.net/mailman/listinfo/dtn-users > > >_______________________________________________ >dtn-users mailing list >dtn-users@maillists.intel-research.net >http://maillists.intel-research.net/mailman/listinfo/dtn-users ------=_NextPart_000_0016_01C9592D.A71B62C0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKtTCCA2Ew ggJJoAMCAQICAhwzMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMDgwNjI3MjA0NTEyWhcNMDkxMjE5MjA0NTEyWjBWMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEVMBMGCgmSJomT8ixkAQETBWpidXNoMRgwFgYDVQQDEw9C dXNoIEplZmZyZXkgRC4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKIAhldyfonlF/aWaHLg Fqhw1QV2YBkox11Fw98vgjGvJTfsdwwSnP6mxH5HLiDAcpv3FTTQnC2SB/YxeAegPoqIktceA2Ww 2acTpQLp1DHulcxtnEG3pmv6AwpGO77hUcVVF2lC7czF5j9t/m3H9hnYxmqcBx77JGyES060+7MZ AgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQWBBTLCLnhPmFRXByDup1S/jysjuv4 VzAfBgNVHSMEGDAWgBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRw Oi8vd3d3Lm1pdHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwGgYDVR0RBBMw EYEPamJ1c2hAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAoqGuAriAsuQmR98gd5/VVc15H D579SdtvzosVljwgZXX9FI/aniCw1rt7cryWIVbblk5gteOPWiUAR2XVA0M+FLA0TWOz9bDxJZlh CJ/tGTXIMrnlO5Ea2cTTviNH4s9uvNwp53u//U3pcuciVW5xPS+Y8vlB87oSkHI73uJYk2nfzNUB /kvMj8oLVkElyBWAUvdvG+B4aJL6WVoI3OJAQjx9UnSWDooqSVIhc9kdDRzx4Kt6IsXqwYWmj1OZ qQaYmJY3b2s45zd/rBlFjIyVpyyi2G3xhgQTlubDg5QiSCJQrpqA/G8cbydsNBquRM3o/0QyQgML vn5N4D905dzlMIIDZDCCAkygAwIBAgIBATANBgkqhkiG9w0BAQUFADBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEkMCIGA1UEAxMbTUlUUkUgQ29y cG9yYXRpb24gUm9vdCBDQS0xMB4XDTA2MDYwMTA0MDAwMFoXDTE4MDYwMTA0MDAwMFowWjESMBAG A1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJDAiBgNVBAMT G01JVFJFIENvcnBvcmF0aW9uIFJvb3QgQ0EtMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAK9rWpY9mIQm/m8y0JuO3RxO7Q1ufXlDVwqpAFcqLxVIf3Nk+Y/F9aLMknslKoUnn+wtTPc2 ydRWOktgF0VzE1ec4uNe2YM8U57CblP3w1lz3BFEKIPO3h/yqwcUjX1KE+Irdw3lSq0l/6LrpBUs DVLoI0vqjZ4YCwCXlafHA6HYF9xZTl82UcNVz0ooCUMNakeMLYsscBRss/hnMwgkpwuAsoUy2AzY AR9pIfOaLtZR1QdEK0JuWsXurM+zL+MEsWuvxVxf6Zvuxqr3mkQ6KWByLHT+dpbuQl8zmmHtQEH5 LU786Ef5mNDgyNafATwD9gOtDHU5UsA6Lb0GyGj+XyUCAwEAAaM1MDMwEgYDVR0TAQH/BAgwBgEB /wIBAzAdBgNVHQ4EFgQUx3BRANhN/uQB1GiWxT2fmpf+dC8wDQYJKoZIhvcNAQEFBQADggEBABr5 9V8KWOKYGVx9bCR8le5c0pa6f3GWgUqOerpI8aAAgqLktQOKXrRrQ1o0agZI7cjXHNi3udxrKHbW pe6VxVMMWq5tIl2/nVodO4lhxhRfvYs3+BKrTdRUsEInNibtktSWRvZgujvFR5ndygsVxPkAdHfq SMbhxgepeAfSWIGXyPGk3SDCBpyLiyA8tSPXDi3zOgof7PEYXBfBM/8/561CqIlnlPTR8submTP2 aafHGaYi9QY12wICEaF2cXbilytHjcs2DI4En0M9QcE2reRRBE7jxYErEHF+U60rOwgLH8cS0gAF xmft14AMdxj2ylQtl8GdBh0SnLPm2CHtjaowggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUA MFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcNMTIw NjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPnhlflKPFPMXGG+iqG pImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI7fnUWiUasNP2ING19aAf rQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407K1i+7WnrRsMVKhICfgmiO/Xi VR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClHDtPJs7UOTjMYBS2fTzztC+wwOTp6 +A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQAB o4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYDVR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9I jWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAWgBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8E QTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1pdHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRy ZV9vcmcuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IA e7u60LK0V9jVZ9E2a+c0MZiSojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8 WDPzlud/WQAzkjrU2nuh8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680 ukiJ9yF6UmEXuciB77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXt p3DIrVqE/DZr146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7Nqg MYICvTCCArkCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRl IEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIcMzAJ BgUrDgMCGgUAoIIBsDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w ODEyMDgxNzA4MTZaMCMGCSqGSIb3DQEJBDEWBBSn2BG1TRyXLUMP3yJi4dlE/bsIMzBnBgkqhkiG 9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTByBgkrBgEEAYI3EAQxZTBj MF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScw JQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAhwzMHQGCyqGSIb3DQEJEAIL MWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIcMzANBgkqhkiG9w0B AQEFAASBgJfpKRNZXDujrewEALBdLGwNmsP6sek6MRu607eYaOUUgfo5WZ+D012ORdzJQP5oCNVQ MNtkmrQn7C6A5jbMjqlkj+oafi38vIfUSt+j0LfAp3SUzgUgKzvIXiBJhEJ4v3ftf4HAW87vOrq/ qeEFKLuHQe2S/BXlbAdA0lbqhBXKAAAAAAAA ------=_NextPart_000_0016_01C9592D.A71B62C0-- Received: from asmtpout021.mac.com (asmtpout021.mac.com [17.148.16.96]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mB6BU8rG010494 for ; Sat, 6 Dec 2008 03:30:08 -0800 MIME-version: 1.0 Content-type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Received: from [192.168.0.3] (78-33-82-89.static.enta.net [78.33.82.89]) by asmtp021.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KBG00GTVC0P3S40@asmtp021.mac.com> for dtn-users@mailman.dtnrg.org; Sat, 06 Dec 2008 03:02:52 -0800 (PST) Message-id: <51C497E0-C933-4FBB-B138-DEBD815DFD56@mac.com> From: Darren Long To: dtn-users mailing list In-reply-to: <4939A580.20506@gaia.arc.nasa.gov> Date: Sat, 06 Dec 2008 11:02:49 +0000 References: <615B3901F7E97940A46DF9A53BB5D4BAFDC835@IMCSRV7.MITRE.ORG> <4939A580.20506@gaia.arc.nasa.gov> X-Mailer: Apple Mail (2.929.2) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id mB6BU8rG010494 Subject: Re: [dtn-users] DTN2 with NORM, build problem on OSX X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2008 11:30:08 -0000 As a quick hack, I made NORMReceiver::process_data() public and added some casts, and now have a NORM link up between my eee (running Ubuntu- eee) and the MacBook Pro, and carrying bundles. Good stuff! Some more experimenting with this, then back to getting ION to talk to a dtnd ;-) Darren On 5 Dec 2008, at 22:04, Don Sullivan wrote: > > I'm getting the following errors building DTN2 with NORM support: > > conv_layers/NORMReceiver.cc: In member function ‘virtual void > dtn::ReceiveWatermark::run(dtn::NORMReceiver*)’: > conv_layers/NORMReceiver.cc:269: warning: format ‘%i’ expects type > ‘int’, but argument 4 has type ‘size_t’ > conv_layers/NORMReceiver.cc:341: error: invalid conversion from > ‘size_t*’ to ‘unsigned int*’ > conv_layers/NORMReceiver.cc:341: error: initializing argument 3 of > ‘bool NormNodeGetCommand(const void*, char*, unsigned int*)’ > conv_layers/NORMReceiver.cc: In member function ‘bool > dtn::ReceiveWatermark::BundleReassemblyBuf::check_completes(bool)’: > conv_layers/NORMReceiver.cc:134: error: ‘void > dtn::NORMReceiver::process_data(u_char*, size_t)’ is protected > conv_layers/NORMReceiver.cc:543: error: within this context > conv_layers/NORMReceiver.cc:134: error: ‘void > dtn::NORMReceiver::process_data(u_char*, size_t)’ is protected > conv_layers/NORMReceiver.cc:546: error: within this context > > Help, please... > > Thanks, > Don > > oasys-1.3.0 with xerces-c and bdb4.6 > NORM Version 1.4b4, with DTN2 patch > DTN2 2.6.0 from mercurial > gcc-4.0.1 i686-apple-darwin9 > Darwin Kernel Version 9.5.0 (10.5.5) > > -- > --------------------------------------------- > Don Sullivan > NASA Ames Research Center > MS 242-4 > Moffett Field, CA 94035-1000 > Office: 650 604 0526 > Mobile: 650 714 9742 > email: donald.v.sullivan@nasa.gov > OR: yes_its_don@mac.com > --------------------------------------------- > Better Die Standing, Than Live Kneeling > - Sic gorgiamus allos subjectatos nunc > > _______________________________________________ > dtn-users mailing list > dtn-users@maillists.intel-research.net > http://maillists.intel-research.net/mailman/listinfo/dtn-users Received: from asmtpout022.mac.com (asmtpout022.mac.com [17.148.16.97]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mB61piNB016896 for ; Fri, 5 Dec 2008 17:51:44 -0800 MIME-version: 1.0 Content-type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Received: from [192.168.0.3] (78-33-82-89.static.enta.net [78.33.82.89]) by asmtp022.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KBF00MEFL90JO50@asmtp022.mac.com> for dtn-users@mailman.dtnrg.org; Fri, 05 Dec 2008 17:24:39 -0800 (PST) Message-id: <08E3268B-134D-432F-8117-EC937510E157@mac.com> From: Darren Long To: dtn-users mailing list In-reply-to: <4939A580.20506@gaia.arc.nasa.gov> Date: Sat, 06 Dec 2008 01:24:35 +0000 References: <615B3901F7E97940A46DF9A53BB5D4BAFDC835@IMCSRV7.MITRE.ORG> <4939A580.20506@gaia.arc.nasa.gov> X-Mailer: Apple Mail (2.929.2) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id mB61piNB016896 Subject: Re: [dtn-users] DTN2 with NORM, build problem on OSX X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2008 01:51:44 -0000 I confirm this on Mac OS X 10.5.5 Intel too. Clean build on Ubuntu x86-32. Darren On 5 Dec 2008, at 22:04, Don Sullivan wrote: > > I'm getting the following errors building DTN2 with NORM support: > > conv_layers/NORMReceiver.cc: In member function ‘virtual void > dtn::ReceiveWatermark::run(dtn::NORMReceiver*)’: > conv_layers/NORMReceiver.cc:269: warning: format ‘%i’ expects type > ‘int’, but argument 4 has type ‘size_t’ > conv_layers/NORMReceiver.cc:341: error: invalid conversion from > ‘size_t*’ to ‘unsigned int*’ > conv_layers/NORMReceiver.cc:341: error: initializing argument 3 of > ‘bool NormNodeGetCommand(const void*, char*, unsigned int*)’ > conv_layers/NORMReceiver.cc: In member function ‘bool > dtn::ReceiveWatermark::BundleReassemblyBuf::check_completes(bool)’: > conv_layers/NORMReceiver.cc:134: error: ‘void > dtn::NORMReceiver::process_data(u_char*, size_t)’ is protected > conv_layers/NORMReceiver.cc:543: error: within this context > conv_layers/NORMReceiver.cc:134: error: ‘void > dtn::NORMReceiver::process_data(u_char*, size_t)’ is protected > conv_layers/NORMReceiver.cc:546: error: within this context > > Help, please... > > Thanks, > Don > > oasys-1.3.0 with xerces-c and bdb4.6 > NORM Version 1.4b4, with DTN2 patch > DTN2 2.6.0 from mercurial > gcc-4.0.1 i686-apple-darwin9 > Darwin Kernel Version 9.5.0 (10.5.5) > > -- > --------------------------------------------- > Don Sullivan > NASA Ames Research Center > MS 242-4 > Moffett Field, CA 94035-1000 > Office: 650 604 0526 > Mobile: 650 714 9742 > email: donald.v.sullivan@nasa.gov > OR: yes_its_don@mac.com > --------------------------------------------- > Better Die Standing, Than Live Kneeling > - Sic gorgiamus allos subjectatos nunc > > _______________________________________________ > dtn-users mailing list > dtn-users@maillists.intel-research.net > http://maillists.intel-research.net/mailman/listinfo/dtn-users Received: from vishnu.arc.nasa.gov (vishnu.arc.nasa.gov [143.232.155.60]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mB5MVnbC008000 for ; Fri, 5 Dec 2008 14:31:50 -0800 Received: from vishnu.arc.nasa.gov (localhost [127.0.0.1]) by vishnu.arc.nasa.gov (Postfix) with ESMTP id 923034402CC; Fri, 5 Dec 2008 14:04:48 -0800 (PST) Message-ID: <4939A580.20506@gaia.arc.nasa.gov> Date: Fri, 05 Dec 2008 14:04:48 -0800 From: Don Sullivan User-Agent: Thunderbird 2.0.0.18pre (Macintosh/20081101) MIME-Version: 1.0 To: "Bush, Jeff" References: <615B3901F7E97940A46DF9A53BB5D4BAFDC835@IMCSRV7.MITRE.ORG> In-Reply-To: <615B3901F7E97940A46DF9A53BB5D4BAFDC835@IMCSRV7.MITRE.ORG> Content-Type: multipart/mixed; boundary="------------080907090309010009060205" Cc: dtn-users mailing list Subject: [dtn-users] DTN2 with NORM, build problem on OSX X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2008 22:31:50 -0000 This is a multi-part message in MIME format. --------------080907090309010009060205 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I'm getting the following errors building DTN2 with NORM support: conv_layers/NORMReceiver.cc: In member function ‘virtual void dtn::ReceiveWatermark::run(dtn::NORMReceiver*)’: conv_layers/NORMReceiver.cc:269: warning: format ‘%i’ expects type ‘int’, but argument 4 has type ‘size_t’ conv_layers/NORMReceiver.cc:341: error: invalid conversion from ‘size_t*’ to ‘unsigned int*’ conv_layers/NORMReceiver.cc:341: error: initializing argument 3 of ‘bool NormNodeGetCommand(const void*, char*, unsigned int*)’ conv_layers/NORMReceiver.cc: In member function ‘bool dtn::ReceiveWatermark::BundleReassemblyBuf::check_completes(bool)’: conv_layers/NORMReceiver.cc:134: error: ‘void dtn::NORMReceiver::process_data(u_char*, size_t)’ is protected conv_layers/NORMReceiver.cc:543: error: within this context conv_layers/NORMReceiver.cc:134: error: ‘void dtn::NORMReceiver::process_data(u_char*, size_t)’ is protected conv_layers/NORMReceiver.cc:546: error: within this context Help, please... Thanks, Don oasys-1.3.0 with xerces-c and bdb4.6 NORM Version 1.4b4, with DTN2 patch DTN2 2.6.0 from mercurial gcc-4.0.1 i686-apple-darwin9 Darwin Kernel Version 9.5.0 (10.5.5) -- --------------------------------------------- Don Sullivan NASA Ames Research Center MS 242-4 Moffett Field, CA 94035-1000 Office: 650 604 0526 Mobile: 650 714 9742 email: donald.v.sullivan@nasa.gov OR: yes_its_don@mac.com --------------------------------------------- Better Die Standing, Than Live Kneeling - Sic gorgiamus allos subjectatos nunc --------------080907090309010009060205 Content-Type: text/x-vcard; charset=utf-8; name="dsullivan.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dsullivan.vcf" begin:vcard fn:Don Sullivan n:Sullivan;Don org:NASA Ames Research Center;Biospheric Science, Science Directorate adr:;;MS 242-4;Moffett Field;CA;94035;USA email;internet:donald.v.sullivan@nasa.gov title:Computer Jockey/Sr Engineer tel;work:+1 650 604 0526 tel;cell:+1 650 714 9742 version:2.1 end:vcard --------------080907090309010009060205-- Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mB5G3MoD022798 for ; Fri, 5 Dec 2008 08:03:23 -0800 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mB5FaSp2030642 for ; Fri, 5 Dec 2008 10:36:28 -0500 Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mB5FaRic030614; Fri, 5 Dec 2008 10:36:27 -0500 Received: from IMCSRV7.MITRE.ORG ([129.83.20.57]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Dec 2008 10:36:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 5 Dec 2008 10:36:26 -0500 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0038_01C956C5.534078D0" Message-ID: <615B3901F7E97940A46DF9A53BB5D4BAFDC835@IMCSRV7.MITRE.ORG> In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [dtn-users] NORM CL questions Thread-Index: AclW67eOG0Bla3/ZROaLWANgoXxBUwAASLaw References: From: "Bush, Jeff" To: "Darren Long" , "dtn-users mailing list" X-OriginalArrivalTime: 05 Dec 2008 15:36:27.0891 (UTC) FILETIME=[3D17C430:01C956EF] Subject: Re: [dtn-users] NORM CL questions X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2008 16:03:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0038_01C956C5.534078D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Darren, >I noticed the inclusion of a NORM CL in the sourceforge repo, and >would like to give it a whirl. I stumbled across NORM a year or two >ago, but never got around to trying it out. > >I've downloaded the last release (also have the daily, but will try >that later when I've figured out what I need to do). I've built the >NORM bins and libs (raft, norm, libnorm.a and libnorm.so) and will >give them a whirl in their own right shortly, when I figure out what >to do with them. > >I wondered if anyone can shed any light on how to go about trying NORM >out in the DTN2 context. Tips on building DTN2 with NORM enabled, and >on link configuration would be appreciated. You'll find installation steps in doc/norm_conv_layer.txt. Assuming you have the NORM libraries available (libnorm.a, libProtokit.a), supply --with-norm to DTN2 configure and recompile. Now try setting up a pair of links with all the defaults: link add norm_link :4557 ALWAYSON norm Once you can dtnping across this link, use Wireshark and decode as NORM. This will give you some indication of what's happening. doc/norm_conv_layer.txt also documents a number of link options that are available. I tried to expose as many NORM features that made sense for DTN. Good luck! -Jeff ------=_NextPart_000_0038_01C956C5.534078D0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKtTCCA2Ew ggJJoAMCAQICAhwzMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt YXJ5IENBLTEwHhcNMDgwNjI3MjA0NTEyWhcNMDkxMjE5MjA0NTEyWjBWMRIwEAYDVQQKEwltaXRy ZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEVMBMGCgmSJomT8ixkAQETBWpidXNoMRgwFgYDVQQDEw9C dXNoIEplZmZyZXkgRC4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKIAhldyfonlF/aWaHLg Fqhw1QV2YBkox11Fw98vgjGvJTfsdwwSnP6mxH5HLiDAcpv3FTTQnC2SB/YxeAegPoqIktceA2Ww 2acTpQLp1DHulcxtnEG3pmv6AwpGO77hUcVVF2lC7czF5j9t/m3H9hnYxmqcBx77JGyES060+7MZ AgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdDgQWBBTLCLnhPmFRXByDup1S/jysjuv4 VzAfBgNVHSMEGDAWgBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRw Oi8vd3d3Lm1pdHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwGgYDVR0RBBMw EYEPamJ1c2hAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAoqGuAriAsuQmR98gd5/VVc15H D579SdtvzosVljwgZXX9FI/aniCw1rt7cryWIVbblk5gteOPWiUAR2XVA0M+FLA0TWOz9bDxJZlh CJ/tGTXIMrnlO5Ea2cTTviNH4s9uvNwp53u//U3pcuciVW5xPS+Y8vlB87oSkHI73uJYk2nfzNUB /kvMj8oLVkElyBWAUvdvG+B4aJL6WVoI3OJAQjx9UnSWDooqSVIhc9kdDRzx4Kt6IsXqwYWmj1OZ qQaYmJY3b2s45zd/rBlFjIyVpyyi2G3xhgQTlubDg5QiSCJQrpqA/G8cbydsNBquRM3o/0QyQgML vn5N4D905dzlMIIDZDCCAkygAwIBAgIBATANBgkqhkiG9w0BAQUFADBaMRIwEAYDVQQKEwltaXRy ZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEkMCIGA1UEAxMbTUlUUkUgQ29y cG9yYXRpb24gUm9vdCBDQS0xMB4XDTA2MDYwMTA0MDAwMFoXDTE4MDYwMTA0MDAwMFowWjESMBAG A1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJDAiBgNVBAMT G01JVFJFIENvcnBvcmF0aW9uIFJvb3QgQ0EtMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAK9rWpY9mIQm/m8y0JuO3RxO7Q1ufXlDVwqpAFcqLxVIf3Nk+Y/F9aLMknslKoUnn+wtTPc2 ydRWOktgF0VzE1ec4uNe2YM8U57CblP3w1lz3BFEKIPO3h/yqwcUjX1KE+Irdw3lSq0l/6LrpBUs DVLoI0vqjZ4YCwCXlafHA6HYF9xZTl82UcNVz0ooCUMNakeMLYsscBRss/hnMwgkpwuAsoUy2AzY AR9pIfOaLtZR1QdEK0JuWsXurM+zL+MEsWuvxVxf6Zvuxqr3mkQ6KWByLHT+dpbuQl8zmmHtQEH5 LU786Ef5mNDgyNafATwD9gOtDHU5UsA6Lb0GyGj+XyUCAwEAAaM1MDMwEgYDVR0TAQH/BAgwBgEB /wIBAzAdBgNVHQ4EFgQUx3BRANhN/uQB1GiWxT2fmpf+dC8wDQYJKoZIhvcNAQEFBQADggEBABr5 9V8KWOKYGVx9bCR8le5c0pa6f3GWgUqOerpI8aAAgqLktQOKXrRrQ1o0agZI7cjXHNi3udxrKHbW pe6VxVMMWq5tIl2/nVodO4lhxhRfvYs3+BKrTdRUsEInNibtktSWRvZgujvFR5ndygsVxPkAdHfq SMbhxgepeAfSWIGXyPGk3SDCBpyLiyA8tSPXDi3zOgof7PEYXBfBM/8/561CqIlnlPTR8submTP2 aafHGaYi9QY12wICEaF2cXbilytHjcs2DI4En0M9QcE2reRRBE7jxYErEHF+U60rOwgLH8cS0gAF xmft14AMdxj2ylQtl8GdBh0SnLPm2CHtjaowggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUA MFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcNMTIw NjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPnhlflKPFPMXGG+iqG pImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI7fnUWiUasNP2ING19aAf rQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407K1i+7WnrRsMVKhICfgmiO/Xi VR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClHDtPJs7UOTjMYBS2fTzztC+wwOTp6 +A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL/6bpvx0DnkrlR2UFr1KBGfBqmQIDAQAB o4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYDVR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9I jWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAWgBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8E QTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1pdHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRy ZV9vcmcuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IA e7u60LK0V9jVZ9E2a+c0MZiSojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8 WDPzlud/WQAzkjrU2nuh8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680 ukiJ9yF6UmEXuciB77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXt p3DIrVqE/DZr146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7Nqg MYICvTCCArkCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRl IEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIcMzAJ BgUrDgMCGgUAoIIBsDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w ODEyMDUxNTM2MjZaMCMGCSqGSIb3DQEJBDEWBBRAOtj3rTDXioIdnmDSTkxfgeoMKTBnBgkqhkiG 9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTByBgkrBgEEAYI3EAQxZTBj MF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScw JQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAhwzMHQGCyqGSIb3DQEJEAIL MWWgYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIcMzANBgkqhkiG9w0B AQEFAASBgI1rOgvYxvtSiuccY8Rc7aWzN4PA2HDQcT4vL8wNWX9Fx2Ri/7WNbgGlBtRtBgr3x2Jn yDjlW19SwE8igAGcblqMZfjv/xNcPCA8Pp2To24v/xyrzoHx8qTcYlDU/qfeYcruhCaayg/C2Xp0 cnIstD8HdhtFqL/lwm8wlwyAYXyHAAAAAAAA ------=_NextPart_000_0038_01C956C5.534078D0-- Received: from asmtpout016.mac.com (asmtpout016.mac.com [17.148.16.91]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id mB5FbSle021531 for ; Fri, 5 Dec 2008 07:37:28 -0800 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.0.3] (78-33-82-89.static.enta.net [78.33.82.89]) by asmtp016.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KBE0034JST63720@asmtp016.mac.com> for dtn-users@mailman.dtnrg.org; Fri, 05 Dec 2008 07:10:20 -0800 (PST) Message-id: From: Darren Long To: dtn-users mailing list Date: Fri, 05 Dec 2008 15:10:18 +0000 X-Mailer: Apple Mail (2.929.2) Subject: [dtn-users] NORM CL questions X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2008 15:37:28 -0000 Hi all, I noticed the inclusion of a NORM CL in the sourceforge repo, and would like to give it a whirl. I stumbled across NORM a year or two ago, but never got around to trying it out. I've downloaded the last release (also have the daily, but will try that later when I've figured out what I need to do). I've built the NORM bins and libs (raft, norm, libnorm.a and libnorm.so) and will give them a whirl in their own right shortly, when I figure out what to do with them. I wondered if anyone can shed any light on how to go about trying NORM out in the DTN2 context. Tips on building DTN2 with NORM enabled, and on link configuration would be appreciated. Finally, but perhaps should have been firstly, does it work yet? Cheers, Darren