Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j5MKkUV19061 for ; Wed, 22 Jun 2005 13:46:30 -0700 Received: by wproxy.gmail.com with SMTP id 69so73724wra for ; Wed, 22 Jun 2005 13:46:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UKvumpHy5ZdEUqGJvoAjPWvZ8FtiY89IvO/0tnf3NfWQZQHsoh2scb8T6oHHO770oA6Xw/r7QXRnw1flrMEZOBHE+0gaIWAbL8gdnx1X80ekfATJrHNrMhpETrJyQZynmO9GdFEhArGW5db+v3isBok03AtpIbGQP9BQUHvaJpg= Received: by 10.54.114.6 with SMTP id m6mr701423wrc; Wed, 22 Jun 2005 13:46:29 -0700 (PDT) Received: by 10.54.24.4 with HTTP; Wed, 22 Jun 2005 13:46:29 -0700 (PDT) Message-ID: <528fa01a05062213462fdad405@mail.gmail.com> Date: Wed, 22 Jun 2005 13:46:29 -0700 From: Melissa Ho To: dtn-users@mailman.dtnrg.org Subject: Re: [dtn-users] end-to-end ACK In-Reply-To: <1119441120.42b950e0aae9d@posta.studio.unibo.it> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <1118736111.42ae8ef019568@posta.studio.unibo.it> <20050614155856.GA7316@pisco.cs.berkeley.edu> <1118766448.42af05701f226@posta.studio.unibo.it> <20050614184155.GF2190@pisco.cs.berkeley.edu> <1119348368.42b7e690643ec@posta.studio.unibo.it> <528fa01a050621075514b201d9@mail.gmail.com> <1119441120.42b950e0aae9d@posta.studio.unibo.it> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by webbie.berkeley.intel-research.net id j5MKkUV19061 Sender: dtn-users-admin@mailman.dtnrg.org Errors-To: dtn-users-admin@mailman.dtnrg.org X-BeenThere: dtn-users@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-users@mailman.dtnrg.org X-Reply-To: mrh9@cornell.edu List-Unsubscribe: , List-Id: discussion/answers list for users of the dtn reference implementation List-Post: List-Help: List-Subscribe: , List-Archive: > (http://dast.nlanr.net/Projects/Iperf). So i can say "send n bytes" and know how > much time did it take, or "send data for n seconds" and get how many bytes have > been sent. This might be problematic to measure, depending on how you've coded your dtniperf - since dtn handles fragmentation, then a large bundle may be sent and received in the daemons as several constituent parts, but only delivered as a single data unit to the application. The optional service flags may be useful in this respect - but you also need to make sure that you are bound to the dtn replyto address in order to receive the reports, or even the replies. You'll notice that dtnping uses both the sending and receiving functions of the applib. > The problem is that the only acknowledge my application can get is when all the > data have been delivered to the sender's daemon, and even if i can see the > daemon receiving all the ACKs from destination, my application cannot capture them. My best guess is that you are not necessarily running dtn_recv with the correct tuple or on the right handle - you'll need to bind using the correct demux string. Your application should be able to capture them if the daemon is receiving them. Any chance you are restarting the daemon or the registration is lost/overwritten? > Then tried to run dtnping: i expected to find much more delay, due to the fact > that bundles have to cross the bundle layers of sender, gateway and receiver. > source_tuple [earth host://susy/ping.2830] > replyto_tuple [earth host://susy/ping.2830] > dtn_register succeeded, regid 0xb > checking for bundles already queued... > PING [sky host://rita]... > 70 bytes from [sky host://rita]: time=168.57 ms > 70 bytes from [sky host://rita]: time=249.31 ms This is the normal delay, without the machine introducing intermediary delay. My guesses are 1) routing configuration is such that the machine is being bypassed... or 2) there is another old dtnd with the same configuration somewhere else on your network that's responding or 3) umberto is misconfigured to respond to pings to rita. What is your dtn link configuration on each node? > I thought that dtnping should capture end-to-end ACKs, but it's not like that. > It only captures ACKs that sender's daemon produces when receives a bundle (i > guess). dtnping uses the RETURN_RCPT flag as specified in the bundle protocol - and there is a "ping" application built into the daemon that receives and discards bundles destined for localtuple/ping.*, after sending the bundle report back to the replyto address. dtnping actually disregards this data, and just measures the RTT based on the local receive time. So anyways... this should work... melissa Received: from pisco.cs.berkeley.edu (pisco.CS.Berkeley.EDU [128.32.37.175]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j5MJXtV18634 for ; Wed, 22 Jun 2005 12:33:55 -0700 Received: from demmer by pisco.cs.berkeley.edu with local (Exim 4.50) id 1DlAyi-0005TS-ML for dtn-users@mailman.dtnrg.org; Wed, 22 Jun 2005 12:33:40 -0700 Date: Wed, 22 Jun 2005 12:33:40 -0700 From: Michael Demmer To: dtn-users@mailman.dtnrg.org Message-ID: <20050622193340.GH2190@pisco.cs.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i Subject: [dtn-users] [demmer@cs.berkeley.edu: Re: maximum payload size] Sender: dtn-users-admin@mailman.dtnrg.org Errors-To: dtn-users-admin@mailman.dtnrg.org X-BeenThere: dtn-users@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-users@mailman.dtnrg.org List-Unsubscribe: , List-Id: discussion/answers list for users of the dtn reference implementation List-Post: List-Help: List-Subscribe: , List-Archive: (posting response to dtn-users after clipping some text so it fits within the 40K max posting limit) ----- Forwarded message from Michael Demmer ----- From: Michael Demmer To: "piero.cornice@studio.unibo.it" Subject: Re: maximum payload size Date: Wed, 22 Jun 2005 10:09:53 -0700 Sorry it took so long for me to get back to you... the problem in this is that for some reason, the payload length of the bundle is ending up as zero, and the current code doesn't handle that well. My suspicion is that there's a problem in the IPC layer when sending bundles of that size. I'm in the process of some pretty heavy rework of the internal bundle forwarding logic, so this may have to wait, but i'll try to figure out what the problem is shortly. Or, if you're feeling up to it, try to trace the logic in the dtn_send api call to see why only a zero-length payload is being handled. -m > I've attached the output of "dtnd -t -l debug". > The sender is called "susy" and the receiver "umberto". I asked to send a 50001 > bytes payload. > > Thanks, > Piero > > > Scrive Michael Demmer : > > > > > Can you also attach the log output from running with -l debug? > > > > -m > > > [1118999812.147869 /dtnd info] Bundle Daemon Initializing... > [1118999812.147930 /dtnd info] random seed is 147925 > [1118999812.147950 /thread debug] activating thread creation barrier > [1118999812.150005 /command/help debug] help command registering > [1118999812.150038 /command/log debug] creating string binding for logfile -> 0x80d9964 > [1118999812.150060 /command/log debug] log command registering > [1118999812.150076 /command/debug debug] debug command registering > [1118999812.150165 /command/test debug] creating int binding for id -> 0xbffffc80 > [1118999812.150185 /command/test debug] creating string binding for initscript -> 0xbffffc84 > [1118999812.150201 /command/test debug] creating string binding for argv -> 0xbffffc88 > [1118999812.150217 /command/test debug] creating bool binding for fork -> 0xbffffc8c > [1118999812.150232 /command/test debug] test command registering > [1118999812.150253 /command/bundle debug] bundle command registering > [1118999812.150271 /command/interface debug] interface command registering > [1118999812.150286 /command/link debug] link command registering > [1118999812.150305 /command/param debug] creating int binding for payload_mem_threshold -> 0x80d7df4 > [1118999812.150321 /command/param debug] creating bool binding for payload_test_no_remove -> 0x80d7df8 > [1118999812.150336 /command/param debug] creating int binding for proactive_frag_threshold -> 0x80d7e88 > [1118999812.150352 /command/param debug] creating int binding for tcpcl_partial_ack_len -> 0x80d7e28 > [1118999812.150367 /command/param debug] creating int binding for tcpcl_keepalive_interval -> 0x80d7e34 > [1118999812.150383 /command/param debug] creating int binding for tcpcl_idle_close_time -> 0x80d7e38 > [1118999812.150400 /command/param debug] creating int binding for tcpcl_test_fragment_size -> 0x80d7e44 > [1118999812.150414 /command/param debug] param command registering > [1118999812.150429 /command/registration debug] registration command registering > [1118999812.150446 /command/route debug] creating string binding for type -> 0x80d7e60 > [1118999812.150461 /command/route debug] route command registering > [1118999812.150479 /command/storage debug] creating string binding for type -> 0x80d9510 > [1118999812.150495 /command/storage debug] creating bool binding for tidy -> 0x80d9515 > [1118999812.150510 /command/storage debug] creating int binding for tidy_wait -> 0x80d9518 > [1118999812.150540 /command/storage debug] creating string binding for dbname -> 0x80d951c > [1118999812.150557 /command/storage debug] creating string binding for dbdir -> 0x80d9520 > [1118999812.150572 /command/storage debug] creating string binding for dberrlog -> 0x80d9524 > [1118999812.150588 /command/storage debug] creating string binding for payloaddir -> 0x80d7df0 > [1118999812.150602 /command/storage debug] storage command registering > [1118999812.150617 /dtnserver debug] registered dtn commands > [1118999812.150637 /command/api debug] creating in_addr_t binding for local_addr -> 0x80d7de0 > [1118999812.150652 /command/api debug] creating int binding for local_port -> 0x80d7de4 > [1118999812.150666 /command/api debug] api command registering > [1118999812.150694 /timer/signal debug] created pipe, fds: 3 4 > [1118999812.150730 /thread debug] delaying start of thread 0x80e5180 due to barrier > [1118999812.150744 /log debug] adding log reparse signal handler > [1118999812.150756 /timer debug] adding signal handler 0x8091144 for signal 1 > [1118999812.150768 /log debug] adding log rotate signal handler > [1118999812.150778 /timer debug] adding signal handler 0x80910ec for signal 10 > [1118999812.150824 /notifier/0x80e588c debug] created pipe, fds: 5 6 > [1118999812.150844 /notifier/0x80e590c debug] created pipe, fds: 7 8 > [1118999812.150876 /notifier/0x80e5dd0 debug] created pipe, fds: 9 10 > [1118999812.150892 /dtnserver debug] intialized dtn components > [1118999812.150916 /dtnd info] parsing configuration file /etc/dtn.conf... > [1118999812.150928 /command debug] executing command file /etc/dtn.conf > [1118999812.151027 /dtnd info] dtnd parsing configuration... > [1118999812.151164 /interface info] adding interface tcp host://0.0.0.0:5000/ > [1118999812.151193 /cl/tcp debug] adding interface host://0.0.0.0:5000/ > [1118999812.151256 /cl/tcp/iface/0.0.0.0:5000 debug] created socket 11 > [1118999812.151267 /cl/tcp/iface/0.0.0.0:5000 debug] setting SO_REUSEADDR > [1118999812.151283 /cl/tcp/iface/0.0.0.0:5000 debug] binding to 0.0.0.0:5000 > [1118999812.151304 /cl/tcp/iface/0.0.0.0:5000 debug] listening > [1118999812.151325 /cl/tcp/iface/0.0.0.0:5000 debug] state INIT -> LISTENING > [1118999812.151337 /thread debug] delaying start of thread 0x80e67b0 due to barrier > [1118999812.151366 /interface info] adding interface udp host://0.0.0.0:6000/ > [1118999812.151378 /cl/udp debug] adding interface host://0.0.0.0:6000/ > [1118999812.151404 /cl/udp/iface/0.0.0.0:6000 debug] created socket 12 > [1118999812.151414 /cl/udp/iface/0.0.0.0:6000 debug] setting SO_REUSEADDR > [1118999812.151425 /cl/udp/iface/0.0.0.0:6000 debug] binding to 0.0.0.0:6000 > [1118999812.151438 /thread debug] delaying start of thread 0x80e6874 due to barrier > [1118999812.151482 /notifier/0x80e6934 debug] created pipe, fds: 13 14 > [1118999812.151498 /link/umberto info] new link umberto: ONDEMAND > [1118999812.151513 /cl/tcp debug] adding ONDEMAND link host://10.0.0.2:5000 > [1118999812.151556 /contact_manager debug] adding link umberto > [1118999812.151584 /notifier/0x80e6a3c debug] created pipe, fds: 15 16 > [1118999812.151598 /peer/host://10.0.0.2:5000 debug] new peer Peer host://10.0.0.2:5000 > [1118999812.151611 /contact_manager debug] adding peer host://10.0.0.2:5000 > [1118999812.151625 /bundle/daemon debug] posting event with type LINK_CREATED > [1118999812.151639 /bundle/daemon debug] posting event with type LINK_AVAILABLE > [1118999812.151673 /bundle/daemon debug] posting event with type ROUTE_ADD > [1118999812.151700 /bundle/daemon debug] posting event with type ROUTE_ADD > [1118999812.151727 /bundle/daemon debug] posting event with type ROUTE_ADD > [1118999812.151753 /bundle/daemon debug] posting event with type ROUTE_ADD > [1118999812.151779 /bundle/daemon debug] posting event with type ROUTE_ADD > [1118999812.151806 /bundle/daemon debug] posting event with type ROUTE_ADD > [1118999812.151832 /bundle/daemon debug] posting event with type ROUTE_ADD > [1118999812.151858 /bundle/daemon debug] posting event with type ROUTE_ADD > [1118999812.151878 /dtnd info] dtnd configuration parsing complete > [1118999812.151899 /dtnserver warning] tidy option removing directory '/bin/rm -rf /var/dtn/bundles' > [1118999812.157553 /dtnserver debug] directory validated: /var/dtn/bundles > [1118999812.157573 /dtnserver debug] directory validated: /var/dtn/db > [1118999812.157772 /berkeleydb/store info] using dbdir = /var/dtn/db, errlog = /var/dtn/db/err.log > [1118999812.157784 /berkeleydb/store warning] PRUNING CONTENTS OF /var/dtn/db IN 3 SECONDS > [1118999813.159391 /berkeleydb/store warning] PRUNING CONTENTS OF /var/dtn/db IN 2 SECONDS > [1118999814.161240 /berkeleydb/store warning] PRUNING CONTENTS OF /var/dtn/db IN 1 SECONDS > [1118999815.168538 /berkeleydb/store info] creating new database directory /var/dtn/db > [1118999815.206570 /berkeleydb/store debug] get_table -- opened table globals > [1118999815.206609 /berkeleydb/store debug] table globals, +refcount=1 > [1118999815.206627 /storage/globals info] initializing global table > [1118999815.206653 /berkeleydb/table(globals) debug] put: serializing 12 byte object > [1118999815.206668 /mutex/lock(0x80ea148) debug] locked (count 1) > [1118999815.206831 /mutex/lock(0x80ea148) debug] unlocked (count 0) > [1118999815.213547 /berkeleydb/store debug] get_table -- opened table bundles > [1118999815.213571 /berkeleydb/store debug] table bundles, +refcount=1 > [1118999815.213607 /route debug] router initializing (local_tuple bundles://earth/host://susy) > [1118999815.213622 /thread debug] delaying start of thread 0x80e5808 due to barrier > [1118999815.213660 /notifier/0x80eba9c debug] created pipe, fds: 20 21 > [1118999815.213678 /bundle/daemon debug] posting event with type REGISTRATION_ADDED > [1118999815.213691 /storage/globals debug] loading global store > [1118999815.213719 /storage/bundles debug] Loading existing bundles from database. > [1118999815.213741 /dtnserver debug] started dtn server > [1118999815.213768 /apiserver debug] APIServer init (addr 127.0.0.1 port 5010) > [1118999815.213789 /apiserver/22 debug] created socket 22 > [1118999815.213800 /apiserver/22 debug] setting SO_REUSEADDR > [1118999815.213812 /apiserver/22 debug] binding to 127.0.0.1:5010 > [1118999815.213827 /apiserver/22 debug] listening > [1118999815.213853 /apiserver/22 debug] state INIT -> LISTENING > [1118999815.213864 /thread debug] delaying start of thread 0x80ebdf4 due to barrier > [1118999815.213878 /thread debug] releasing thread creation barrier -- 5 queued threads > [1118999815.213889 /thread debug] starting thread 0x80e5180 > [1118999815.213946 /thread debug] starting thread 0x80e67b0 > [1118999815.213976 /thread debug] starting thread 0x80e6874 > [1118999815.214002 /thread debug] starting thread 0x80e5808 > [1118999815.214028 /thread debug] starting thread 0x80ebdf4 > [1118999815.219845 /tcl info] can't load tclreadline: can't find package tclreadline > [1118999815.219867 /tcl info] fall back to simple command loop > dtn% [1118999815.220040 /route debug] router executing event LINK_CREATED > [1118999815.220053 /route info] LINK_CREATED umberto: ONDEMAND > [1118999815.220080 /route debug] router executing event LINK_AVAILABLE > [1118999815.220091 /route info] LINK_AVAILABLE umberto: ONDEMAND > [1118999815.220105 /bundle/actions debug] moving 0 bundles from from next hop host://10.0.0.2:5000 (type Peer) to next hop host://10.0.0.2:5000 (type Ondemand Link) > [1118999815.220124 /route debug] router executing event ROUTE_ADD > [1118999815.220137 /route/table debug] add_route bundles://earth/host://sally/* -> host://10.0.0.2:5000 (FORWARD_COPY) > [1118999815.220153 /route debug] new_next_hop host://10.0.0.2:5000: checking pending bundle list... > [1118999815.220166 /route debug] router executing event ROUTE_ADD > [1118999815.220177 /route/table debug] add_route bundles://earth/host://ugo/* -> host://10.0.0.2:5000 (FORWARD_COPY) > [1118999815.220191 /route debug] new_next_hop host://10.0.0.2:5000: checking pending bundle list... > [1118999815.220203 /route debug] router executing event ROUTE_ADD > [1118999815.220215 /route/table debug] add_route bundles://earth/host://umberto/* -> host://10.0.0.2:5000 (FORWARD_COPY) > [1118999815.220227 /route debug] new_next_hop host://10.0.0.2:5000: checking pending bundle list... > [1118999815.220239 /route debug] router executing event ROUTE_ADD > [1118999815.220251 /route/table debug] add_route bundles://sky/host://umberto/* -> host://10.0.0.2:5000 (FORWARD_COPY) > [1118999815.220263 /route debug] new_next_hop host://10.0.0.2:5000: checking pending bundle list... > [1118999815.220275 /route debug] router executing event ROUTE_ADD > [1118999815.220286 /route/table debug] add_route bundles://sky/host://suzanne/* -> host://10.0.0.2:5000 (FORWARD_COPY) > [1118999815.220299 /route debug] new_next_hop host://10.0.0.2:5000: checking pending bundle list... > [1118999815.220311 /route debug] router executing event ROUTE_ADD > [1118999815.220323 /route/table debug] add_route bundles://sky/host://sat/* -> host://10.0.0.2:5000 (FORWARD_COPY) > [1118999815.220334 /route debug] new_next_hop host://10.0.0.2:5000: checking pending bundle list... > [1118999815.220346 /route debug] router executing event ROUTE_ADD > [1118999815.220358 /route/table debug] add_route bundles://sky/host://rita/* -> host://10.0.0.2:5000 (FORWARD_COPY) > [1118999815.220369 /route debug] new_next_hop host://10.0.0.2:5000: checking pending bundle list... > [1118999815.220381 /route debug] router executing event ROUTE_ADD > [1118999815.220392 /route/table debug] add_route bundles://earth/host://rachele/* -> host://10.0.0.2:5000 (FORWARD_COPY) > [1118999815.220404 /route debug] new_next_hop host://10.0.0.2:5000: checking pending bundle list... > [1118999815.220416 /route debug] router executing event REGISTRATION_ADDED > [1118999815.220428 /route debug] new registration for bundles://earth/host://susy > [1118999815.220441 /route/table debug] add_route bundles://earth/host://susy -> bundles://earth/host://susy (FORWARD_REASSEMBLE) > [1118999815.220454 /route debug] new_next_hop bundles://earth/host://susy: checking pending bundle list... > [1118999815.220485 /notifier/0x80e5dd0 debug] poll: events 0x1 timeout -1 revents 0x1 cc 1 > [1118999815.220501 /notifier/0x80e5dd0 debug] drain_pipe: drained 1 byte(s) from pipe > [1118999819.804530 /apiserver/22 debug] accepted connection fd 23 from 127.0.0.1:3644 > [1118999819.804566 /apiclient/23 debug] setting SO_REUSEADDR > [1118999819.804588 /thread debug] starting thread 0x811c878 > [1118999819.805024 /apiclient/23 debug] new session 127.0.0.1:5010 -> 127.0.0.1:3644 > [1118999819.805039 /apiclient/23 debug] read 4/4 > [1118999819.805112 /apiclient/23 debug] write 4/4 > [1118999819.805323 /apiclient/23 debug] read 300/65536 > [1118999819.805336 /apiclient/23 debug] got DTN_REGISTER (292/292 bytes) > [1118999819.805419 /storage/globals debug] next_regid 10 -> 11 > [1118999819.805432 /storage/globals debug] updating global store > [1118999819.805470 /berkeleydb/table(globals) debug] put: serializing 12 byte object > [1118999819.805483 /mutex/lock(0x80ea148) debug] locked (count 1) > [1118999819.809074 /mutex/lock(0x80ea148) debug] unlocked (count 0) > [1118999819.809104 /notifier/0x8110d3c debug] created pipe, fds: 24 25 > [1118999819.809126 /registration info] adding registration 10/bundles://earth/host://susy/src > [1118999819.809140 /bundle/daemon debug] posting event with type REGISTRATION_ADDED > [1118999819.809161 /notifier/0x80e5dd0 debug] poll: events 0x1 timeout -1 revents 0x1 cc 1 > [1118999819.809182 /notifier/0x80e5dd0 debug] drain_pipe: drained 1 byte(s) from pipe > [1118999819.809194 /route debug] router executing event REGISTRATION_ADDED > [1118999819.809204 /route debug] new registration for bundles://earth/host://susy/src > [1118999819.809217 /route/table debug] add_route bundles://earth/host://susy/src -> bundles://earth/host://susy/src (FORWARD_REASSEMBLE) > [1118999819.809229 /route debug] new_next_hop bundles://earth/host://susy/src: checking pending bundle list... > [1118999819.809248 /apiclient/23 debug] building reply: status (unknown type), length 4 > [1118999819.809259 /apiclient/23 debug] sending 12 byte reply message > [1118999819.809524 /apiclient/23 debug] writeall 12/12 > [1118999819.809538 /apiclient/23 debug] read 288/65536 > [1118999819.809550 /apiclient/23 debug] got DTN_BIND (280/280 bytes) > [1118999819.809581 /apiclient/23 debug] building reply: status (unknown type), length 0 > [1118999819.809593 /apiclient/23 debug] sending 8 byte reply message > [1118999819.907843 /apiclient/23 debug] writeall 8/8 > [1118999819.907865 /apiclient/23 debug] read 860/65536 > [1118999819.907878 /apiclient/23 debug] got DTN_SEND (852/852 bytes) > [1118999819.907921 /storage/globals debug] next_bundleid 0 -> 1 > [1118999819.907933 /storage/globals debug] updating global store > [1118999819.907978 /berkeleydb/table(globals) debug] put: serializing 12 byte object > [1118999819.907990 /mutex/lock(0x80ea148) debug] locked (count 1) > [1118999819.908199 /mutex/lock(0x80ea148) debug] unlocked (count 0) > [1118999819.908218 /bundle debug] Bundle::init bundle id 0 > [1118999819.908277 /bundle/payload/0 debug] open /var/dtn/bundles/bundle_0.dat (flags 0xc2 mode 0x180): fd 26 > [1118999819.908332 /bundle/payload/0 debug] writeall 0/0 > [1118999819.908362 /bundle/payload/0 debug] close /var/dtn/bundles/bundle_0.dat fd 26: 0 > [1118999819.908376 /bundle/refs debug] bundle id 0: refcount 0 -> 1 (0 mappings) add BundleReceivedEvent > [1118999819.908389 /bundle/daemon debug] posting event with type BUNDLE_RECEIVED > [1118999819.908408 /notifier/0x80e5dd0 debug] poll: events 0x1 timeout -1 revents 0x1 cc 1 > [1118999819.908423 /notifier/0x80e5dd0 debug] drain_pipe: drained 1 byte(s) from pipe > [1118999819.908435 /route debug] router executing event BUNDLE_RECEIVED > [1118999819.908445 /route info] BUNDLE_RECEIVED id:0 (0 of 0 bytes) > [1118999819.908456 /route debug] bundle 0 source bundles://earth/host://susy/src > [1118999819.908467 /route debug] bundle 0 dest bundles://earth/host://umberto/dest > [1118999819.908476 /route debug] bundle 0 replyto bundles://earth/host://susy/src > [1118999819.908485 /route debug] bundle 0 custodian bundles://earth/host://susy > [1118999819.908517 /bundle/refs debug] bundle id 0: refcount 1 -> 2 (0 mappings) add bundle_list pending_bundles > [1118999819.908530 /bundle/mapping debug] bundle id 0 add mapping [pending_bundles] > [1118999819.908546 /bundle/actions debug] adding bundle 0 to data store > [1118999819.908563 /berkeleydb/table(bundles) debug] put: serializing 187 byte object > [1118999819.908574 /mutex/lock(0x80eb500) debug] locked (count 1) > [1118999819.908674 /apiclient/23 debug] building reply: status (unknown type), length 0 > [1118999819.908687 /apiclient/23 debug] sending 8 byte reply message > [1118999819.908764 /mutex/lock(0x80eb500) debug] unlocked (count 0) > [1118999819.908780 /route/table debug] get_matching bundles://earth/host://umberto/dest > [1118999819.908792 /route/table debug] check entry bundles://earth/host://sally/* -> host://10.0.0.2:5000 (FORWARD_COPY) > [1118999819.908813 /af/internet debug] match failed: url hosts not equal ('sally' != 'umberto') > [1118999819.908827 /route/table debug] check entry bundles://earth/host://ugo/* -> host://10.0.0.2:5000 (FORWARD_COPY) > [1118999819.908846 /af/internet debug] match failed: url hosts not equal ('ugo' != 'umberto') > [1118999819.908859 /route/table debug] check entry bundles://earth/host://umberto/* -> host://10.0.0.2:5000 (FORWARD_COPY) > [1118999819.908878 /af/internet debug] match succeeded: pattern 'umberto' admin 'umberto' > [1118999819.908891 /route/table debug] match entry bundles://earth/host://umberto/* -> host://10.0.0.2:5000 (FORWARD_COPY) > [1118999819.908905 /route/table debug] check entry bundles://sky/host://umberto/* -> host://10.0.0.2:5000 (FORWARD_COPY) > [1118999819.908917 /route/table debug] check entry bundles://sky/host://suzanne/* -> host://10.0.0.2:5000 (FORWARD_COPY) > [1118999819.908929 /route/table debug] check entry bundles://sky/host://sat/* -> host://10.0.0.2:5000 (FORWARD_COPY) > [1118999819.908940 /route/table debug] check entry bundles://sky/host://rita/* -> host://10.0.0.2:5000 (FORWARD_COPY) > [1118999819.908952 /route/table debug] check entry bundles://earth/host://rachele/* -> host://10.0.0.2:5000 (FORWARD_COPY) > [1118999819.908971 /af/internet debug] match failed: url hosts not equal ('rachele' != 'umberto') > [1118999819.908984 /route/table debug] check entry bundles://earth/host://susy -> bundles://earth/host://susy (FORWARD_REASSEMBLE) > [1118999819.909004 /af/internet debug] match failed: url hosts not equal ('susy' != 'umberto') > [1118999819.909017 /route/table debug] check entry bundles://earth/host://susy/src -> bundles://earth/host://susy/src (FORWARD_REASSEMBLE) > [1118999819.909036 /af/internet debug] match failed: url hosts not equal ('susy' != 'umberto') > [1118999819.909049 /route/table debug] get_matching bundles://earth/host://umberto/dest done, 1 match(es) > [1118999819.909062 /bundle/pending debug] bundle id 0: add pendingtxcount 0 -> 1 > [1118999819.909074 /route info] Opening ONDEMAND link umberto because messages are queued for it > [1118999819.909085 /bundle/actions debug] opening link umberto > [1118999819.909096 /link/umberto debug] Link::open > [1118999819.909119 /notifier/0x811027c debug] created pipe, fds: 26 27 > [1118999819.909135 /contact/host://10.0.0.2:5000 info] new contact umberto: ONDEMAND > [1118999819.909153 /cl/tcp debug] opening contact umberto: ONDEMAND > [1118999819.909184 /thread debug] starting thread 0x810fe94 > [1118999819.909267 /bundle/actions debug] enqueue bundle 0 on next hop host://10.0.0.2:5000 (type Ondemand Link) > [1118999819.909281 /link/umberto debug] Link umberto is open, so queueing it on contact queue > [1118999819.909293 /contact/host://10.0.0.2:5000 info] enqueue bundle id 0 for delivery to host://10.0.0.2:5000 > [1118999819.909306 /bundle/refs debug] bundle id 0: refcount 2 -> 3 (1 mappings) add bundle_list /contact/host://10.0.0.2:5000 > [1118999819.909319 /bundle/mapping debug] bundle id 0 add mapping [/contact/host://10.0.0.2:5000] > [1118999819.909334 /cl/tcp debug] sending bundles for contact umberto: ONDEMAND > [1118999819.909360 /route debug] fwd_to_matching bundles://earth/host://umberto/dest: 1 matches > [1118999819.909374 /bundle/refs debug] bundle id 0: refcount 3 -> 2 (2 mappings) del BundleReceivedEvent > [1118999819.909407 /cl/tcp/conn/10.0.0.2:5000 debug] connect: connecting to 10.0.0.2:5000... > [1118999819.909429 /cl/tcp/conn/10.0.0.2:5000/sock debug] created socket 28 > [1118999819.909440 /cl/tcp/conn/10.0.0.2:5000/sock debug] setting SO_REUSEADDR > [1118999819.909453 /cl/tcp/conn/10.0.0.2:5000/sock debug] connecting to 10.0.0.2:5000 > [1118999819.909464 /cl/tcp/conn/10.0.0.2:5000/sock debug] state INIT -> CONNECTING > [1118999819.909665 /cl/tcp/conn/10.0.0.2:5000/sock debug] EINPROGRESS from connect(), calling poll() > [1118999819.909891 /apiclient/23 debug] writeall 8/8 > [1118999819.909904 /apiclient/23 debug] read 16/65536 > [1118999819.910038 /cl/tcp/conn/10.0.0.2:5000/sock debug] poll: events 0x4 timeout 10000 revents 0x4 cc 1 > [1118999819.910057 /cl/tcp/conn/10.0.0.2:5000/sock debug] return from poll, connect succeeded > [1118999819.910068 /cl/tcp/conn/10.0.0.2:5000/sock debug] state CONNECTING -> ESTABLISHED > [1118999819.910081 /cl/tcp/conn/10.0.0.2:5000 debug] connect: connection established, sending contact header... > [1118999819.910160 /cl/tcp/conn/10.0.0.2:5000/sock debug] writeall 12/12 > [1118999819.910172 /cl/tcp/conn/10.0.0.2:5000 debug] connect: waiting for contact header reply... > [1118999819.910188 /apiclient/23 debug] got DTN_RECV (8/8 bytes) > [1118999819.910202 /apiclient/23 debug] handle_recv: blocking to get bundle for registration 10 (timeout -1) > [1118999819.910627 /cl/tcp/conn/10.0.0.2:5000/sock debug] poll: events 0x3 timeout 5000 revents 0x1 cc 1 > [1118999819.910645 /cl/tcp/conn/10.0.0.2:5000 debug] noting receipt of data > [1118999819.910663 /bundle/daemon debug] posting event with type CONTACT_UP > [1118999819.910680 /notifier/0x80e5dd0 debug] poll: events 0x1 timeout -1 revents 0x1 cc 1 > [1118999819.910699 /notifier/0x80e5dd0 debug] drain_pipe: drained 1 byte(s) from pipe > [1118999819.910710 /route debug] router executing event CONTACT_UP > [1118999819.910720 /route info] CONTACT_UP umberto: ONDEMAND > [1118999819.910743 /bundle/actions debug] moving 0 bundles from from next hop host://10.0.0.2:5000 (type Ondemand Link) to next hop host://10.0.0.2:5000 (type Contact) > [1118999819.910762 /cl/tcp/conn/10.0.0.2:5000 info] connection established -- (keepalive time 2 seconds) > [1118999819.910796 /cl/tcp/conn/10.0.0.2:5000 debug] send_bundle: bundle id 0, header_length 81 payload_length 0 > [1118999819.910808 /cl/tcp/conn/10.0.0.2:5000 debug] send_bundle: sending 13 byte tcpcl hdr, 81 byte bundle hdr > [1118999819.910882 /cl/tcp/conn/10.0.0.2:5000/sock debug] writev 94/94 > [1118999819.910897 /bundle/payload/0 debug] close /var/dtn/bundles/bundle_0.dat fd -1: -1 > [1118999819.910920 /cl/tcp/conn/10.0.0.2:5000 debug] send_bundle: bundle id 0, header_length 81 payload_length 0 > [1118999819.910932 /cl/tcp/conn/10.0.0.2:5000 debug] send_bundle: sending 13 byte tcpcl hdr, 81 byte bundle hdr > [1118999819.910945 /cl/tcp/conn/10.0.0.2:5000/sock debug] writev 94/94 > [1118999819.910957 /bundle/payload/0 debug] close /var/dtn/bundles/bundle_0.dat fd -1: -1 > [1118999819.910979 /cl/tcp/conn/10.0.0.2:5000 debug] send_bundle: bundle id 0, header_length 81 payload_length 0 > [1118999819.910991 /cl/tcp/conn/10.0.0.2:5000 debug] send_bundle: sending 13 byte tcpcl hdr, 81 byte bundle hdr > [1118999819.911014 /cl/tcp/conn/10.0.0.2:5000/sock debug] writev 94/94 > [1118999819.911026 /bundle/payload/0 debug] close /var/dtn/bundles/bundle_0.dat fd -1: -1 > [1118999819.911048 /cl/tcp/conn/10.0.0.2:5000 debug] send_bundle: bundle id 0, header_length 81 payload_length 0 > [1118999819.911060 /cl/tcp/conn/10.0.0.2:5000 debug] send_bundle: sending 13 byte tcpcl hdr, 81 byte bundle hdr > [1118999819.911072 /cl/tcp/conn/10.0.0.2:5000/sock debug] writev 94/94 > [1118999819.911083 /bundle/payload/0 debug] close /var/dtn/bundles/bundle_0.dat fd -1: -1 ----- End forwarded message ----- Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j5MInPV18271 for ; Wed, 22 Jun 2005 11:49:25 -0700 Received: by wproxy.gmail.com with SMTP id 58so30911wri for ; Wed, 22 Jun 2005 11:49:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cq3ZDCbG8YP+m3EGf3X3G2OJvpExp80FGDW7SpCe2KKA86lwHYEXuIJS98kOEkplX0HaGM9x5nw4XvySPqHryaZ+PqO/EmTQ7w916YC05v30I4j8fBS7zTQBKWhrwWU8c+h/OhMF5X+aerL7KE+iXO4+o2pdux78OlFr0iLRNK4= Received: by 10.54.28.70 with SMTP id b70mr628531wrb; Wed, 22 Jun 2005 11:49:24 -0700 (PDT) Received: by 10.54.109.2 with HTTP; Wed, 22 Jun 2005 11:49:24 -0700 (PDT) Message-ID: <5f30e26105062211492e062608@mail.gmail.com> Date: Wed, 22 Jun 2005 13:49:24 -0500 From: Jeff Wilson To: dtn-bugs@mailman.dtnrg.org, dtn-users@mailman.dtnrg.org In-Reply-To: <20050608202801.GK22270@pisco.cs.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <5f30e26105060811394a4bd44a@mail.gmail.com> <20050608202801.GK22270@pisco.cs.berkeley.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by webbie.berkeley.intel-research.net id j5MInPV18271 Subject: [dtn-users] Re: [dtn-bugs] error compiling CVS code Sender: dtn-users-admin@mailman.dtnrg.org Errors-To: dtn-users-admin@mailman.dtnrg.org X-BeenThere: dtn-users@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-users@mailman.dtnrg.org X-Reply-To: Jeff Wilson List-Unsubscribe: , List-Id: discussion/answers list for users of the dtn reference implementation List-Post: List-Help: List-Subscribe: , List-Archive: FYI, I pulled down today's CVS and successfully compiled DTN2 using gcc 3.4.2 on Fedora Core 3. The "gcc 3.4.x chokes on certain DTN init macros" bug has been fixed. Thanks again for all your effort on this project! Regards, jw On 6/8/05, Michael Demmer wrote: > > The version in the CVS repository has been undergoing some flux in > recent days related to some new refactoring of the initialization > sequence. We expect that this and the other identified problems will > be fixed within a week or so. > > In the meantime, this particular problem only shows up with gcc 3.4 so > you could try downgrading your compiler or just backing out to the > version from a couple weeks ago. > > -m > > > > Hi all, > > > > I ran `cvs up -Pd` for the first time in a while, then got the > > following error after `configure -C && make`: > > > > g++ -I. -g -fno-inline -MMD -MP -MT "storage/BerkeleyDBStore.o > > storage/BerkeleyDBStore.E storage/BerkeleyDBStore.po" -Wall -Werror > > -c storage/BerkeleyDBStore.cc -o storage/BerkeleyDBStore.o > > storage/BerkeleyDBStore.cc:70: error: too few template-parameter-lists > > storage/BerkeleyDBStore.cc:70: error: expected `,' or `;' before '=' token > > make[1]: *** [storage/BerkeleyDBStore.o] Error 1 > > make[1]: Leaving directory `/path/to/dtn/DTN2/oasys' > > make: *** [oasys] Error 2 > > > > The following snippet from BerkeleyDBStore.cc is the offender: > > > > /* > > * BerkeleyDB depends on StorageConfig > > */ > > OASYS_DECLARE_INIT_MODULE_1(oasys, BerkeleyDBStore, "oasys::StorageConfig") { > > BerkeleyDBStore::init(); > > return 0; > > } > > > > Thanks for your time, > > jw > > _______________________________________________ > > dtn-bugs mailing list > > dtn-bugs@mailman.dtnrg.org > > http://mailman.dtnrg.org/mailman/listinfo/dtn-bugs > Received: from pisco.cs.berkeley.edu (pisco.CS.Berkeley.EDU [128.32.37.175]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j5MGvoV17320 for ; Wed, 22 Jun 2005 09:57:50 -0700 Received: from demmer by pisco.cs.berkeley.edu with local (Exim 4.50) id 1Dl8Xu-0004ut-NM for dtn-users@mailman.dtnrg.org; Wed, 22 Jun 2005 09:57:50 -0700 Date: Wed, 22 Jun 2005 09:57:50 -0700 From: Michael Demmer To: dtn-users@mailman.dtnrg.org Subject: Re: [dtn-users] end-to-end ACK Message-ID: <20050622165750.GB18824@pisco.cs.berkeley.edu> References: <1118736111.42ae8ef019568@posta.studio.unibo.it> <20050614155856.GA7316@pisco.cs.berkeley.edu> <1118766448.42af05701f226@posta.studio.unibo.it> <20050614184155.GF2190@pisco.cs.berkeley.edu> <1119348368.42b7e690643ec@posta.studio.unibo.it> <528fa01a050621075514b201d9@mail.gmail.com> <1119441120.42b950e0aae9d@posta.studio.unibo.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1119441120.42b950e0aae9d@posta.studio.unibo.it> User-Agent: Mutt/1.4.2i Sender: dtn-users-admin@mailman.dtnrg.org Errors-To: dtn-users-admin@mailman.dtnrg.org X-BeenThere: dtn-users@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-users@mailman.dtnrg.org List-Unsubscribe: , List-Id: discussion/answers list for users of the dtn reference implementation List-Post: List-Help: List-Subscribe: , List-Archive: I think there may be something wrong with your configuration (or something non-obvious wrong with the dtnd software), because the ping application should be responding only to end-to-end acks, as would be expected. First of all, when you run your experiment, make sure you run dtnd --tidy (or dtnd -t) to clean out any old bundles from the persistent data store and retry your test. If it still looks like things aren't working right, run dtnd -l debug to enable debugging output, and for each of your dtnd executables, capture all the output. Then look in each one for the line "generating return receipt status report". That should only be emitted by rita, after the 600ms delay. My instinct is that you may have some other invalid configuration, like a conflicting local registration or something like that, which is causing some other dtnd to respond with return receipts. In any event, you've described your problem in enough detail that if you also attach the -l debug output, I should be able to figure out what's going on. -m > Thanks for your answer, I'll try to explain the problem the best I can... > > I have to do some tests on a DTN net made up by a sender (named "susy" in region > "earth"), a receiver (named "rita" in region "sky") and a gateway (named > "umberto", belonging to both regions). Between the gateway and the receiver > there's a machine (trasparent to DTN) which introduces a 600ms delay. > I wrote an application, similar to dtnsend, which wants to behave like Iperf > (http://dast.nlanr.net/Projects/Iperf). So i can say "send n bytes" and know how > much time did it take, or "send data for n seconds" and get how many bytes have > been sent. > The problem is that the only acknowledge my application can get is when all the > data have been delivered to the sender's daemon, and even if i can see the > daemon receiving all the ACKs from destination, my application cannot capture them. > To be sure of that, i tried to run a simple ping from the sender to the > receiver, and this is the output: > > PING rita (10.1.2.5) 56(84) bytes of data. > > 64 bytes from rita (10.1.2.5): icmp_seq=1 ttl=61 time=601 ms > 64 bytes from rita (10.1.2.5): icmp_seq=2 ttl=61 time=600 ms > 64 bytes from rita (10.1.2.5): icmp_seq=3 ttl=61 time=600 ms > 64 bytes from rita (10.1.2.5): icmp_seq=4 ttl=61 time=600 ms > 64 bytes from rita (10.1.2.5): icmp_seq=5 ttl=61 time=600 ms > 64 bytes from rita (10.1.2.5): icmp_seq=6 ttl=61 time=600 ms > ................. > > As you can see, there's a 600ms delay, due to the presence of the transparent > machine i described above. > Then tried to run dtnping: i expected to find much more delay, due to the fact > that bundles have to cross the bundle layers of sender, gateway and receiver. > That's the output: > > source_tuple [earth host://susy/ping.2830] > replyto_tuple [earth host://susy/ping.2830] > dtn_register succeeded, regid 0xb > checking for bundles already queued... > PING [sky host://rita]... > 70 bytes from [sky host://rita]: time=168.57 ms > 70 bytes from [sky host://rita]: time=249.31 ms > 70 bytes from [sky host://rita]: time=223.34 ms > 70 bytes from [sky host://rita]: time=223.33 ms > 70 bytes from [sky host://rita]: time=232.50 ms > 70 bytes from [sky host://rita]: time=215.31 ms > 70 bytes from [sky host://rita]: time=213.31 ms > 70 bytes from [sky host://rita]: time=224.33 ms > 70 bytes from [sky host://rita]: time=223.34 ms > ................. > > The delay is almost 1/3 of TCP's! How is it possible, when there's the machine > introducing a 600ms delay? > I thought that dtnping should capture end-to-end ACKs, but it's not like that. > It only captures ACKs that sender's daemon produces when receives a bundle (i > guess). > So, is there a way to obtain the effective Round-Trip-Time of a DTN > communication, possibly using the Bundle Layer APIs? > > Thanks, > Piero Cornice, Bologna, Italy > > > > Scrive Melissa Ho : > > > Hi guys, > > > > I think I missed the original context, but as far as I know (and can > > tell) dtnsend actually supports end-to-end reciepts (-e, > > return_receipts), and optionally blocking for the dtn_ecv call (-w > > wait_for_report). I added it ages ago. The only thing is that it only > > waits for a single report. > > > > If you want to wait for all of the reports, you should run dtnrecv > > with the replyto address (-r) when you run dtnsend. Anything sent to > > that address (unless you pick one being used for something else) > > should be the bundle reports. You can recognize them because they will > > fit the format for bundle reports as specified in the protocol draft. > > The flag marking it as a report in the header should be on as well. > > > > I believe dtnrecv dumps the contents of the bundle as a printed > > hexdump. If you want to have it dump into a file so you can look at > > it later, I suggest you use dtncpd to receive the file. > > > > Melissa > > > > On 6/21/05, piero.cornice@studio.unibo.it > > wrote: > > > > That would require some specific coding in the dtnsend application > > > > that doesn't exist now. It wouldn't be hard, you'd basically mark the > > > > bundle that end-to-end ack was requested and then write a loop to > > > > optionally block in the dtn_recv API call waiting for the return > > > > receipt bundle to arrive. > > > > > > I've written (main instructions only): > > > > > > memset(®info, 0, sizeof(reginfo)); > > > dtn_copy_tuple(®info.endpoint, &bundle_spec.replyto); > > > > > > reginfo.action = DTN_REG_ABORT; > > > reginfo.regid = regid; > > > reginfo.timeout = 60 * 60; > > > > > > ret = dtn_register(handle, ®info, ®id) > > > dtn_bind(handle, regid, &bundle_spec.replyto); > > > > > > and then I've marked the outgoing bundle with the return-receipt and > > > receive-receipt options: > > > > > > bundle_spec.dopts |= DOPTS_RETURN_RCPT; > > > bundle_spec.dopts |= DOPTS_RECV_RCPT; > > > > > > Now, how could I recognise whether an incoming bundle is the end-to-end-ACK > > bundle? > > > I think this should be quite similar to dtnping, but really don't > > understand how > > > to have end-to-end ACK... > > > I also read the Bundle Protocol Specification document but didn't find how > > to do > > > this. > > > > > > > > > > > If you do make this change and would like it to be folded into the > > > > main distribution, please then post a diff here. > > > > > > > > thanks > > > > -m > > > > > > > > > > I'll be glad to do that, but i'd need some help :-) > > > Thanks, > > > Piero, Italy > > > > > > _______________________________________________ > > > dtn-users mailing list > > > dtn-users@mailman.dtnrg.org > > > http://mailman.dtnrg.org/mailman/listinfo/dtn-users > > > > > _______________________________________________ > > dtn-users mailing list > > dtn-users@mailman.dtnrg.org > > http://mailman.dtnrg.org/mailman/listinfo/dtn-users > > > > > > > > > _______________________________________________ > dtn-users mailing list > dtn-users@mailman.dtnrg.org > http://mailman.dtnrg.org/mailman/listinfo/dtn-users Received: from as2.cineca.com (as2.cineca.com [130.186.84.242]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j5MBq6V15665 for ; Wed, 22 Jun 2005 04:52:06 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by as2.cineca.com (Postfix) with ESMTP id D7E406593C for ; Wed, 22 Jun 2005 11:52:04 +0000 (UTC) Received: from unibo.mm.cineca.it (unibo.mm.cineca.it [130.186.10.202]) by as2.cineca.com (Postfix) with ESMTP id 6738E65944 for ; Wed, 22 Jun 2005 11:52:01 +0000 (UTC) Received: from localhost (unibo.mm.cineca.it [130.186.10.202]) as user anonymous by unibo.mm.cineca.it (Postfix) with ESMTP id B29253D779E for ; Wed, 22 Jun 2005 13:52:00 +0200 (MEST) Received: from 81.208.74.187 ( [81.208.74.187]) as user piero.cornice@studio.unibo.it@posta.studio.unibo.it by posta.studio.unibo.it with HTTP; Wed, 22 Jun 2005 13:52:00 +0200 Message-ID: <1119441120.42b950e0aae9d@posta.studio.unibo.it> Date: Wed, 22 Jun 2005 13:52:00 +0200 From: "piero.cornice@studio.unibo.it" To: dtn-users@mailman.dtnrg.org Subject: Re: [dtn-users] end-to-end ACK References: <1118736111.42ae8ef019568@posta.studio.unibo.it> <20050614155856.GA7316@pisco.cs.berkeley.edu> <1118766448.42af05701f226@posta.studio.unibo.it> <20050614184155.GF2190@pisco.cs.berkeley.edu> <1119348368.42b7e690643ec@posta.studio.unibo.it> <528fa01a050621075514b201d9@mail.gmail.com> In-Reply-To: <528fa01a050621075514b201d9@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 81.208.74.187 X-Virus-Scanned: Cineca AppOs 0.85 at as2.cineca.com Sender: dtn-users-admin@mailman.dtnrg.org Errors-To: dtn-users-admin@mailman.dtnrg.org X-BeenThere: dtn-users@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-users@mailman.dtnrg.org List-Unsubscribe: , List-Id: discussion/answers list for users of the dtn reference implementation List-Post: List-Help: List-Subscribe: , List-Archive: Thanks for your answer, I'll try to explain the problem the best I can... I have to do some tests on a DTN net made up by a sender (named "susy" in region "earth"), a receiver (named "rita" in region "sky") and a gateway (named "umberto", belonging to both regions). Between the gateway and the receiver there's a machine (trasparent to DTN) which introduces a 600ms delay. I wrote an application, similar to dtnsend, which wants to behave like Iperf (http://dast.nlanr.net/Projects/Iperf). So i can say "send n bytes" and know how much time did it take, or "send data for n seconds" and get how many bytes have been sent. The problem is that the only acknowledge my application can get is when all the data have been delivered to the sender's daemon, and even if i can see the daemon receiving all the ACKs from destination, my application cannot capture them. To be sure of that, i tried to run a simple ping from the sender to the receiver, and this is the output: PING rita (10.1.2.5) 56(84) bytes of data. 64 bytes from rita (10.1.2.5): icmp_seq=1 ttl=61 time=601 ms 64 bytes from rita (10.1.2.5): icmp_seq=2 ttl=61 time=600 ms 64 bytes from rita (10.1.2.5): icmp_seq=3 ttl=61 time=600 ms 64 bytes from rita (10.1.2.5): icmp_seq=4 ttl=61 time=600 ms 64 bytes from rita (10.1.2.5): icmp_seq=5 ttl=61 time=600 ms 64 bytes from rita (10.1.2.5): icmp_seq=6 ttl=61 time=600 ms ................. As you can see, there's a 600ms delay, due to the presence of the transparent machine i described above. Then tried to run dtnping: i expected to find much more delay, due to the fact that bundles have to cross the bundle layers of sender, gateway and receiver. That's the output: source_tuple [earth host://susy/ping.2830] replyto_tuple [earth host://susy/ping.2830] dtn_register succeeded, regid 0xb checking for bundles already queued... PING [sky host://rita]... 70 bytes from [sky host://rita]: time=168.57 ms 70 bytes from [sky host://rita]: time=249.31 ms 70 bytes from [sky host://rita]: time=223.34 ms 70 bytes from [sky host://rita]: time=223.33 ms 70 bytes from [sky host://rita]: time=232.50 ms 70 bytes from [sky host://rita]: time=215.31 ms 70 bytes from [sky host://rita]: time=213.31 ms 70 bytes from [sky host://rita]: time=224.33 ms 70 bytes from [sky host://rita]: time=223.34 ms ................. The delay is almost 1/3 of TCP's! How is it possible, when there's the machine introducing a 600ms delay? I thought that dtnping should capture end-to-end ACKs, but it's not like that. It only captures ACKs that sender's daemon produces when receives a bundle (i guess). So, is there a way to obtain the effective Round-Trip-Time of a DTN communication, possibly using the Bundle Layer APIs? Thanks, Piero Cornice, Bologna, Italy Scrive Melissa Ho : > Hi guys, > > I think I missed the original context, but as far as I know (and can > tell) dtnsend actually supports end-to-end reciepts (-e, > return_receipts), and optionally blocking for the dtn_ecv call (-w > wait_for_report). I added it ages ago. The only thing is that it only > waits for a single report. > > If you want to wait for all of the reports, you should run dtnrecv > with the replyto address (-r) when you run dtnsend. Anything sent to > that address (unless you pick one being used for something else) > should be the bundle reports. You can recognize them because they will > fit the format for bundle reports as specified in the protocol draft. > The flag marking it as a report in the header should be on as well. > > I believe dtnrecv dumps the contents of the bundle as a printed > hexdump. If you want to have it dump into a file so you can look at > it later, I suggest you use dtncpd to receive the file. > > Melissa > > On 6/21/05, piero.cornice@studio.unibo.it > wrote: > > > That would require some specific coding in the dtnsend application > > > that doesn't exist now. It wouldn't be hard, you'd basically mark the > > > bundle that end-to-end ack was requested and then write a loop to > > > optionally block in the dtn_recv API call waiting for the return > > > receipt bundle to arrive. > > > > I've written (main instructions only): > > > > memset(®info, 0, sizeof(reginfo)); > > dtn_copy_tuple(®info.endpoint, &bundle_spec.replyto); > > > > reginfo.action = DTN_REG_ABORT; > > reginfo.regid = regid; > > reginfo.timeout = 60 * 60; > > > > ret = dtn_register(handle, ®info, ®id) > > dtn_bind(handle, regid, &bundle_spec.replyto); > > > > and then I've marked the outgoing bundle with the return-receipt and > > receive-receipt options: > > > > bundle_spec.dopts |= DOPTS_RETURN_RCPT; > > bundle_spec.dopts |= DOPTS_RECV_RCPT; > > > > Now, how could I recognise whether an incoming bundle is the end-to-end-ACK > bundle? > > I think this should be quite similar to dtnping, but really don't > understand how > > to have end-to-end ACK... > > I also read the Bundle Protocol Specification document but didn't find how > to do > > this. > > > > > > > > If you do make this change and would like it to be folded into the > > > main distribution, please then post a diff here. > > > > > > thanks > > > -m > > > > > > > I'll be glad to do that, but i'd need some help :-) > > Thanks, > > Piero, Italy > > > > _______________________________________________ > > dtn-users mailing list > > dtn-users@mailman.dtnrg.org > > http://mailman.dtnrg.org/mailman/listinfo/dtn-users > > > _______________________________________________ > dtn-users mailing list > dtn-users@mailman.dtnrg.org > http://mailman.dtnrg.org/mailman/listinfo/dtn-users > > Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j5LEtUV21398 for ; Tue, 21 Jun 2005 07:55:30 -0700 Received: by wproxy.gmail.com with SMTP id 71so1315421wri for ; Tue, 21 Jun 2005 07:55:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=K4nuTTJ0girMhPN4rfYSUOYJJxmKRrSDHjGuwZVZ9NEz5AnVaNO8Yz6CR8MSfz+rZPNLDZp0UGnESn/gtrdKRXfxgDRHFV2Rfnz5+vxNq8KzyfBHGp6RpxkTmMgKB1Gw4MwoKDGgKypFMMxrXzo4eMf2hhzUsKaxhmRiVQjeBls= Received: by 10.54.141.13 with SMTP id o13mr1679037wrd; Tue, 21 Jun 2005 07:55:30 -0700 (PDT) Received: by 10.54.24.4 with HTTP; Tue, 21 Jun 2005 07:55:29 -0700 (PDT) Message-ID: <528fa01a050621075514b201d9@mail.gmail.com> Date: Tue, 21 Jun 2005 07:55:30 -0700 From: Melissa Ho To: dtn-users@mailman.dtnrg.org Subject: Re: [dtn-users] end-to-end ACK Cc: Michael Demmer In-Reply-To: <1119348368.42b7e690643ec@posta.studio.unibo.it> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <1118736111.42ae8ef019568@posta.studio.unibo.it> <20050614155856.GA7316@pisco.cs.berkeley.edu> <1118766448.42af05701f226@posta.studio.unibo.it> <20050614184155.GF2190@pisco.cs.berkeley.edu> <1119348368.42b7e690643ec@posta.studio.unibo.it> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by webbie.berkeley.intel-research.net id j5LEtUV21398 Sender: dtn-users-admin@mailman.dtnrg.org Errors-To: dtn-users-admin@mailman.dtnrg.org X-BeenThere: dtn-users@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-users@mailman.dtnrg.org X-Reply-To: mrh9@cornell.edu List-Unsubscribe: , List-Id: discussion/answers list for users of the dtn reference implementation List-Post: List-Help: List-Subscribe: , List-Archive: Hi guys, I think I missed the original context, but as far as I know (and can tell) dtnsend actually supports end-to-end reciepts (-e, return_receipts), and optionally blocking for the dtn_ecv call (-w wait_for_report). I added it ages ago. The only thing is that it only waits for a single report. If you want to wait for all of the reports, you should run dtnrecv with the replyto address (-r) when you run dtnsend. Anything sent to that address (unless you pick one being used for something else) should be the bundle reports. You can recognize them because they will fit the format for bundle reports as specified in the protocol draft. The flag marking it as a report in the header should be on as well. I believe dtnrecv dumps the contents of the bundle as a printed hexdump. If you want to have it dump into a file so you can look at it later, I suggest you use dtncpd to receive the file. Melissa On 6/21/05, piero.cornice@studio.unibo.it wrote: > > That would require some specific coding in the dtnsend application > > that doesn't exist now. It wouldn't be hard, you'd basically mark the > > bundle that end-to-end ack was requested and then write a loop to > > optionally block in the dtn_recv API call waiting for the return > > receipt bundle to arrive. > > I've written (main instructions only): > > memset(®info, 0, sizeof(reginfo)); > dtn_copy_tuple(®info.endpoint, &bundle_spec.replyto); > > reginfo.action = DTN_REG_ABORT; > reginfo.regid = regid; > reginfo.timeout = 60 * 60; > > ret = dtn_register(handle, ®info, ®id) > dtn_bind(handle, regid, &bundle_spec.replyto); > > and then I've marked the outgoing bundle with the return-receipt and > receive-receipt options: > > bundle_spec.dopts |= DOPTS_RETURN_RCPT; > bundle_spec.dopts |= DOPTS_RECV_RCPT; > > Now, how could I recognise whether an incoming bundle is the end-to-end-ACK bundle? > I think this should be quite similar to dtnping, but really don't understand how > to have end-to-end ACK... > I also read the Bundle Protocol Specification document but didn't find how to do > this. > > > > > If you do make this change and would like it to be folded into the > > main distribution, please then post a diff here. > > > > thanks > > -m > > > > I'll be glad to do that, but i'd need some help :-) > Thanks, > Piero, Italy > > _______________________________________________ > dtn-users mailing list > dtn-users@mailman.dtnrg.org > http://mailman.dtnrg.org/mailman/listinfo/dtn-users > Received: from as2.cineca.com (as2.cineca.com [130.186.84.242]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j5LA6EV19441 for ; Tue, 21 Jun 2005 03:06:14 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by as2.cineca.com (Postfix) with ESMTP id 7BB476596B; Tue, 21 Jun 2005 10:06:12 +0000 (UTC) Received: from unibo.mm.cineca.it (unibo.mm.cineca.it [130.186.10.202]) by as2.cineca.com (Postfix) with ESMTP id 333EE6595B; Tue, 21 Jun 2005 10:06:09 +0000 (UTC) Received: from localhost (unibo.mm.cineca.it [130.186.10.202]) as user anonymous by unibo.mm.cineca.it (Postfix) with ESMTP id 7322534945C; Tue, 21 Jun 2005 12:06:08 +0200 (MEST) Received: from 81.208.74.187 ( [81.208.74.187]) as user piero.cornice@studio.unibo.it@posta.studio.unibo.it by posta.studio.unibo.it with HTTP; Tue, 21 Jun 2005 12:06:08 +0200 Message-ID: <1119348368.42b7e690643ec@posta.studio.unibo.it> Date: Tue, 21 Jun 2005 12:06:08 +0200 From: "piero.cornice@studio.unibo.it" To: Michael Demmer Cc: dtn-users@mailman.dtnrg.org References: <1118736111.42ae8ef019568@posta.studio.unibo.it> <20050614155856.GA7316@pisco.cs.berkeley.edu> <1118766448.42af05701f226@posta.studio.unibo.it> <20050614184155.GF2190@pisco.cs.berkeley.edu> In-Reply-To: <20050614184155.GF2190@pisco.cs.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 81.208.74.187 X-Virus-Scanned: Cineca AppOs 0.85 at as2.cineca.com Subject: [dtn-users] end-to-end ACK Sender: dtn-users-admin@mailman.dtnrg.org Errors-To: dtn-users-admin@mailman.dtnrg.org X-BeenThere: dtn-users@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-users@mailman.dtnrg.org List-Unsubscribe: , List-Id: discussion/answers list for users of the dtn reference implementation List-Post: List-Help: List-Subscribe: , List-Archive: > That would require some specific coding in the dtnsend application > that doesn't exist now. It wouldn't be hard, you'd basically mark the > bundle that end-to-end ack was requested and then write a loop to > optionally block in the dtn_recv API call waiting for the return > receipt bundle to arrive. I've written (main instructions only): memset(®info, 0, sizeof(reginfo)); dtn_copy_tuple(®info.endpoint, &bundle_spec.replyto); reginfo.action = DTN_REG_ABORT; reginfo.regid = regid; reginfo.timeout = 60 * 60; ret = dtn_register(handle, ®info, ®id) dtn_bind(handle, regid, &bundle_spec.replyto); and then I've marked the outgoing bundle with the return-receipt and receive-receipt options: bundle_spec.dopts |= DOPTS_RETURN_RCPT; bundle_spec.dopts |= DOPTS_RECV_RCPT; Now, how could I recognise whether an incoming bundle is the end-to-end-ACK bundle? I think this should be quite similar to dtnping, but really don't understand how to have end-to-end ACK... I also read the Bundle Protocol Specification document but didn't find how to do this. > > If you do make this change and would like it to be folded into the > main distribution, please then post a diff here. > > thanks > -m > I'll be glad to do that, but i'd need some help :-) Thanks, Piero, Italy Received: from pisco.cs.berkeley.edu (pisco.CS.Berkeley.EDU [128.32.37.175]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j5KHhLV06406 for ; Mon, 20 Jun 2005 10:43:21 -0700 Received: from demmer by pisco.cs.berkeley.edu with local (Exim 4.50) id 1DkQIr-0004GN-8E for dtn-users@mailman.dtnrg.org; Mon, 20 Jun 2005 10:43:21 -0700 Date: Mon, 20 Jun 2005 10:43:21 -0700 From: Michael Demmer To: dtn-users@mailman.dtnrg.org Subject: Re: [dtn-users] Convergence Layer Message-ID: <20050620174321.GX2190@pisco.cs.berkeley.edu> References: <1119267438.42b6aa6e38e5e@posta.studio.unibo.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1119267438.42b6aa6e38e5e@posta.studio.unibo.it> User-Agent: Mutt/1.4.2i Sender: dtn-users-admin@mailman.dtnrg.org Errors-To: dtn-users-admin@mailman.dtnrg.org X-BeenThere: dtn-users@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-users@mailman.dtnrg.org List-Unsubscribe: , List-Id: discussion/answers list for users of the dtn reference implementation List-Post: List-Help: List-Subscribe: , List-Archive: > Hi, i'd like to know something about implemented TCP Convergence Layer. > I want to send a sequence of a certain number of bundles (let's say 100), each > with a 10000-bytes payload. > So my application calls the dtn_send for each bundle, giving them to the Bundle > Daemon. > Then (if i'm right...) the daemon calls the Convergence Layer and it opens a TCP > connection to the destination machine. > What i'd like to know is whether the Convergence layer detects that many bundles > are in the queue or not, and if it uses an unique TCP connection for all the > bundles or if it opens and closes a new connection for each bundle. The implementation will keep a single open connection and pipeline the bundles one after another on that one connection. -m Received: from as2.cineca.com (as2.cineca.com [130.186.84.242]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j5KBbQV04380 for ; Mon, 20 Jun 2005 04:37:27 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by as2.cineca.com (Postfix) with ESMTP id B27C46599D for ; Mon, 20 Jun 2005 11:37:20 +0000 (UTC) Received: from unibo.mm.cineca.it (unibo.mm.cineca.it [130.186.10.202]) by as2.cineca.com (Postfix) with ESMTP id F379465997 for ; Mon, 20 Jun 2005 11:37:18 +0000 (UTC) Received: from localhost (unibo.mm.cineca.it [130.186.10.202]) as user anonymous by unibo.mm.cineca.it (Postfix) with ESMTP id 4058B353F25 for ; Mon, 20 Jun 2005 13:37:18 +0200 (MEST) Received: from 81.208.74.187 ( [81.208.74.187]) as user piero.cornice@studio.unibo.it@posta.studio.unibo.it by posta.studio.unibo.it with HTTP; Mon, 20 Jun 2005 13:37:18 +0200 Message-ID: <1119267438.42b6aa6e38e5e@posta.studio.unibo.it> Date: Mon, 20 Jun 2005 13:37:18 +0200 From: "piero.cornice@studio.unibo.it" To: dtn-users@mailman.dtnrg.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 81.208.74.187 X-Virus-Scanned: Cineca AppOs 0.85 at as2.cineca.com Subject: [dtn-users] Convergence Layer Sender: dtn-users-admin@mailman.dtnrg.org Errors-To: dtn-users-admin@mailman.dtnrg.org X-BeenThere: dtn-users@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-users@mailman.dtnrg.org List-Unsubscribe: , List-Id: discussion/answers list for users of the dtn reference implementation List-Post: List-Help: List-Subscribe: , List-Archive: Hi, i'd like to know something about implemented TCP Convergence Layer. I want to send a sequence of a certain number of bundles (let's say 100), each with a 10000-bytes payload. So my application calls the dtn_send for each bundle, giving them to the Bundle Daemon. Then (if i'm right...) the daemon calls the Convergence Layer and it opens a TCP connection to the destination machine. What i'd like to know is whether the Convergence layer detects that many bundles are in the queue or not, and if it uses an unique TCP connection for all the bundles or if it opens and closes a new connection for each bundle. Thanks, Piero, Italy Received: from pisco.cs.berkeley.edu (pisco.CS.Berkeley.EDU [128.32.37.175]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j5FJ5WV13991 for ; Wed, 15 Jun 2005 12:05:32 -0700 Received: from demmer by pisco.cs.berkeley.edu with local (Exim 4.50) id 1DidCe-0007P5-3z for dtn-users@mailman.dtnrg.org; Wed, 15 Jun 2005 12:05:32 -0700 Date: Wed, 15 Jun 2005 12:05:32 -0700 From: Michael Demmer To: dtn-users@mailman.dtnrg.org Subject: Re: [dtn-users] maximum file size Message-ID: <20050615190532.GM2190@pisco.cs.berkeley.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i Sender: dtn-users-admin@mailman.dtnrg.org Errors-To: dtn-users-admin@mailman.dtnrg.org X-BeenThere: dtn-users@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-users@mailman.dtnrg.org List-Unsubscribe: , List-Id: discussion/answers list for users of the dtn reference implementation List-Post: List-Help: List-Subscribe: , List-Archive: > Hi, I am trying to send a file from one node to another, and even though > I can successfully send small files(I've tried 3.5KB) but when I try to > send something bigger, I get "error timeout_read error: ..." and > "recv_bundle: error reading bundle data block.." in the receiving node, > and "ASSERTION FAILED( cc == 0 || cc == 1 ) at io/IO.cc:254 in the sending > end. Looks like it's dying from some polling error. Is there a maximum > file size that DTN can currently send that I am not aware of? I didn't > find anything in configuration file that would change such thing. > Thanks! This is an unexpected problem which actually means that the operating system returned an invalid result from the poll() system call. What version and which OS are you running on? What version of the DTN source code are you running? -m Received: from cheetah.cs.ucla.edu (Cheetah.CS.UCLA.EDU [131.179.128.24]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j5F7k8V09169 for ; Wed, 15 Jun 2005 00:46:08 -0700 Received: from localhost (ishimoto@localhost) by cheetah.cs.ucla.edu (8.11.7p1+Sun/8.11.7/UCLACS-5.2) with ESMTP id j5F7k2d23150 for ; Wed, 15 Jun 2005 00:46:02 -0700 (PDT) Date: Wed, 15 Jun 2005 00:46:02 -0700 (PDT) From: Ryutaro Ishimoto To: dtn-users@mailman.dtnrg.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dtn-users] maximum file size Sender: dtn-users-admin@mailman.dtnrg.org Errors-To: dtn-users-admin@mailman.dtnrg.org X-BeenThere: dtn-users@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-users@mailman.dtnrg.org List-Unsubscribe: , List-Id: discussion/answers list for users of the dtn reference implementation List-Post: List-Help: List-Subscribe: , List-Archive: Hi, I am trying to send a file from one node to another, and even though I can successfully send small files(I've tried 3.5KB) but when I try to send something bigger, I get "error timeout_read error: ..." and "recv_bundle: error reading bundle data block.." in the receiving node, and "ASSERTION FAILED( cc == 0 || cc == 1 ) at io/IO.cc:254 in the sending end. Looks like it's dying from some polling error. Is there a maximum file size that DTN can currently send that I am not aware of? I didn't find anything in configuration file that would change such thing. Thanks! Ryu Received: from pisco.cs.berkeley.edu (pisco.CS.Berkeley.EDU [128.32.37.175]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j5EIfuV04317 for ; Tue, 14 Jun 2005 11:41:56 -0700 Received: from demmer by pisco.cs.berkeley.edu with local (Exim 4.50) id 1DiGMF-0002XE-S6; Tue, 14 Jun 2005 11:41:55 -0700 Date: Tue, 14 Jun 2005 11:41:55 -0700 From: Michael Demmer To: "piero.cornice@studio.unibo.it" Cc: dtn-users@mailman.dtnrg.org Subject: Re: [dtn-users] maximum payload size Message-ID: <20050614184155.GF2190@pisco.cs.berkeley.edu> References: <1118736111.42ae8ef019568@posta.studio.unibo.it> <20050614155856.GA7316@pisco.cs.berkeley.edu> <1118766448.42af05701f226@posta.studio.unibo.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1118766448.42af05701f226@posta.studio.unibo.it> User-Agent: Mutt/1.4.2i Sender: dtn-users-admin@mailman.dtnrg.org Errors-To: dtn-users-admin@mailman.dtnrg.org X-BeenThere: dtn-users@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-users@mailman.dtnrg.org List-Unsubscribe: , List-Id: discussion/answers list for users of the dtn reference implementation List-Post: List-Help: List-Subscribe: , List-Archive: > The application that I wrote is structured with a Client-Server model, very > similar to dtnsend/dtnrecv. > In the sender code, I initialize a payload with a pseudo-random fill of bytes, > and then gives it to the demon and the receiver should show the payload content > on the other machine. > Now the payload size is of 10.000 bytes, but when i try to build a > 100.000-bytes-payload bundle, the sender demon refuses to deliver it, and enters > a strange loop. I'd like, however, to build larger bundles... Can you tell me more details of what you mean by "refuses to deliver" or "enters a strange loop"? Also which version of the core you're using. It's hard to debug with these types of vague statements. I'm still interested in seeing that backtrace from the PANIC you mentioned earlier, so please post that when you get a chance. > Another problem: the sender waits until all the bundles are delivered to its > demon, then returns the time used for that operation. Is there a way to make the > sender wait until its demon receives all the ACKs from the receiver? (end-to-end > ACK) > I tried to set global variables, like in dtnsend, but still doesn't > work... That would require some specific coding in the dtnsend application that doesn't exist now. It wouldn't be hard, you'd basically mark the bundle that end-to-end ack was requested and then write a loop to optionally block in the dtn_recv API call waiting for the return receipt bundle to arrive. If you do make this change and would like it to be folded into the main distribution, please then post a diff here. thanks -m Received: from as1.cineca.com (as1.cineca.com [130.186.84.251]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j5EGRWV03529 for ; Tue, 14 Jun 2005 09:27:33 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by as1.cineca.com (Postfix) with ESMTP id 57A1965913; Tue, 14 Jun 2005 16:27:31 +0000 (UTC) Received: from unibo.mm.cineca.it (unibo.mm.cineca.it [130.186.10.202]) by as1.cineca.com (Postfix) with ESMTP id F066F65912; Tue, 14 Jun 2005 16:27:29 +0000 (UTC) Received: from localhost (unibo.mm.cineca.it [130.186.10.202]) as user anonymous by unibo.mm.cineca.it (Postfix) with ESMTP id 5D41629C445; Tue, 14 Jun 2005 18:27:28 +0200 (MEST) Received: from 81.208.74.187 ( [81.208.74.187]) as user piero.cornice@studio.unibo.it@posta.studio.unibo.it by posta.studio.unibo.it with HTTP; Tue, 14 Jun 2005 18:27:28 +0200 Message-ID: <1118766448.42af05701f226@posta.studio.unibo.it> Date: Tue, 14 Jun 2005 18:27:28 +0200 From: "piero.cornice@studio.unibo.it" To: Michael Demmer Cc: dtn-users@mailman.dtnrg.org Subject: Re: [dtn-users] maximum payload size References: <1118736111.42ae8ef019568@posta.studio.unibo.it> <20050614155856.GA7316@pisco.cs.berkeley.edu> In-Reply-To: <20050614155856.GA7316@pisco.cs.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 81.208.74.187 X-Virus-Scanned: Cineca AppOs 0.85 at as1.cineca.com Sender: dtn-users-admin@mailman.dtnrg.org Errors-To: dtn-users-admin@mailman.dtnrg.org X-BeenThere: dtn-users@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-users@mailman.dtnrg.org List-Unsubscribe: , List-Id: discussion/answers list for users of the dtn reference implementation List-Post: List-Help: List-Subscribe: , List-Archive: > As for the maximum payload size, there's a limit of 4GB due to the > fact that the current implementation uses a 32-bit length field. The application that I wrote is structured with a Client-Server model, very similar to dtnsend/dtnrecv. In the sender code, I initialize a payload with a pseudo-random fill of bytes, and then gives it to the demon and the receiver should show the payload content on the other machine. Now the payload size is of 10.000 bytes, but when i try to build a 100.000-bytes-payload bundle, the sender demon refuses to deliver it, and enters a strange loop. I'd like, however, to build larger bundles... Another problem: the sender waits until all the bundles are delivered to its demon, then returns the time used for that operation. Is there a way to make the sender wait until its demon receives all the ACKs from the receiver? (end-to-end ACK) I tried to set global variables, like in dtnsend, but still doesn't work... Thank you (...also for your patience ) Piero, Bologna, Italy Received: from pisco.cs.berkeley.edu (pisco.CS.Berkeley.EDU [128.32.37.175]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j5EFwuV03324 for ; Tue, 14 Jun 2005 08:58:56 -0700 Received: from demmer by pisco.cs.berkeley.edu with local (Exim 4.50) id 1DiDoW-0001ug-6H for dtn-users@mailman.dtnrg.org; Tue, 14 Jun 2005 08:58:56 -0700 Date: Tue, 14 Jun 2005 08:58:56 -0700 From: Michael Demmer To: dtn-users@mailman.dtnrg.org Subject: Re: [dtn-users] maximum payload size Message-ID: <20050614155856.GA7316@pisco.cs.berkeley.edu> References: <1118736111.42ae8ef019568@posta.studio.unibo.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1118736111.42ae8ef019568@posta.studio.unibo.it> User-Agent: Mutt/1.4.2i Sender: dtn-users-admin@mailman.dtnrg.org Errors-To: dtn-users-admin@mailman.dtnrg.org X-BeenThere: dtn-users@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-users@mailman.dtnrg.org List-Unsubscribe: , List-Id: discussion/answers list for users of the dtn reference implementation List-Post: List-Help: List-Subscribe: , List-Archive: No -- this has nothing to do with the size of a bundle. Internally within the daemon, there are several places in which I use atomic instructions to implement a "spin lock", meaning that one thread is busy-waiting while another thread does some short-lived activity. Since no-one should hold the lock for a long time, I added a maximum spin count to the code to ensure that deadlock would be caught, though the actual number of spins to wait for is actually something tricky to figure out. The most useful thing you could do is to look at a core file resulting from the crash and post the backtrace of all threads (to do this in gdb, run "thread apply all where"). That will help me figure out what's going on. As for the maximum payload size, there's a limit of 4GB due to the fact that the current implementation uses a 32-bit length field. That will change when we adopt SDNVs for all lengths. Also, the RPC layer restricts the size of bundles that can be passed in memory, but that shouldn't really be an issue since you can just send/recv big bundles in files. -m > Hi, I'm trying to send bundles between 3 machines in order to check the > bandwidth. I wrote a software (similar to iperf) by which user can set the > transmission time, so a loop sends bundles (10K each time) to destination. > While testing thins software, i had the following error in the bundle demon of > the source machine: > > [1118742777.967735 /route info] BUNDLE_RECEIVED id:1437 (10000 of 10000 bytes) > [1118742778.923541 /panic critical] PANIC at thread/SpinLock.cc:70: SpinLock > reached spin limit > > what does it mean? Did I sent too many bundles? > I'd also like to know which is the maximum payload size of a bundle, and if is > it possible to change it. > Thanks, > Piero Cornice, Bologna, Italy > > _______________________________________________ > dtn-users mailing list > dtn-users@mailman.dtnrg.org > http://mailman.dtnrg.org/mailman/listinfo/dtn-users Received: from as1.cineca.com (as1.cineca.com [130.186.84.251]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j5E81vV32667 for ; Tue, 14 Jun 2005 01:01:58 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by as1.cineca.com (Postfix) with ESMTP id BC1E66593E for ; Tue, 14 Jun 2005 08:01:55 +0000 (UTC) Received: from unibo.mm.cineca.it (unibo.mm.cineca.it [130.186.10.202]) by as1.cineca.com (Postfix) with ESMTP id 0835265939 for ; Tue, 14 Jun 2005 08:01:54 +0000 (UTC) Received: from localhost (unibo.mm.cineca.it [130.186.10.202]) as user anonymous by unibo.mm.cineca.it (Postfix) with ESMTP id 536FF3F2664 for ; Tue, 14 Jun 2005 10:01:52 +0200 (MEST) Received: from 81.208.74.187 ( [81.208.74.187]) as user piero.cornice@studio.unibo.it@posta.studio.unibo.it by posta.studio.unibo.it with HTTP; Tue, 14 Jun 2005 10:01:51 +0200 Message-ID: <1118736111.42ae8ef019568@posta.studio.unibo.it> Date: Tue, 14 Jun 2005 10:01:52 +0200 From: "piero.cornice@studio.unibo.it" To: dtn-users@mailman.dtnrg.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 81.208.74.187 X-Virus-Scanned: Cineca AppOs 0.85 at as1.cineca.com Subject: [dtn-users] maximum payload size Sender: dtn-users-admin@mailman.dtnrg.org Errors-To: dtn-users-admin@mailman.dtnrg.org X-BeenThere: dtn-users@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-users@mailman.dtnrg.org List-Unsubscribe: , List-Id: discussion/answers list for users of the dtn reference implementation List-Post: List-Help: List-Subscribe: , List-Archive: Hi, I'm trying to send bundles between 3 machines in order to check the bandwidth. I wrote a software (similar to iperf) by which user can set the transmission time, so a loop sends bundles (10K each time) to destination. While testing thins software, i had the following error in the bundle demon of the source machine: [1118742777.967735 /route info] BUNDLE_RECEIVED id:1437 (10000 of 10000 bytes) [1118742778.923541 /panic critical] PANIC at thread/SpinLock.cc:70: SpinLock reached spin limit what does it mean? Did I sent too many bundles? I'd also like to know which is the maximum payload size of a bundle, and if is it possible to change it. Thanks, Piero Cornice, Bologna, Italy Received: from pisco (pisco.CS.Berkeley.EDU [128.32.37.175]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j5DGH4V27068; Mon, 13 Jun 2005 09:17:04 -0700 Received: from demmer by pisco with local (Exim 4.50) id 1DhrcW-0005mt-E9; Mon, 13 Jun 2005 09:17:04 -0700 Date: Mon, 13 Jun 2005 09:17:04 -0700 From: Michael Demmer To: Ryutaro Ishimoto Cc: dtn-interest@mailman.dtnrg.org, dtn-users@mailman.dtnrg.org Message-ID: <20050613161704.GF20836@pisco.cs.berkeley.edu> Mail-Followup-To: Ryutaro Ishimoto , dtn-interest@mailman.dtnrg.org, dtn-users@mailman.dtnrg.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i Subject: [dtn-users] Re: [dtn-interest] sending a bundle Sender: dtn-users-admin@mailman.dtnrg.org Errors-To: dtn-users-admin@mailman.dtnrg.org X-BeenThere: dtn-users@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-users@mailman.dtnrg.org List-Unsubscribe: , List-Id: discussion/answers list for users of the dtn reference implementation List-Post: List-Help: List-Subscribe: , List-Archive: First of all, please direct future questions related specifically to the reference implementation to the dtn-users mailing list. The main logic is in DTN2/servlib/routing/BundleRouter.cc, where it consults the route table in response to various events (i.e. a new bundle arrived, a new contact arrived, etc) and then enqueues the bundle on a particular next hop destination. However, we are in the process of refactoring this logic slightly to accomodate running multiple dynamic routing algorithms at the same time, so the interface will be changing in the next release of DTN2. -m > Hi, could someone tell me which file contains the code that a > node determines the next hop to send the bundle? I want to do some tests > where I want DTN to read in my routing table(at this point, just a file) > right before it sends out the bundle. This test is just to see where it > should get the next hop information when dynamic routing becomes > available. Thanks in advance! > > Ryu > _______________________________________________ > dtn-interest mailing list > dtn-interest@mailman.dtnrg.org > http://mailman.dtnrg.org/mailman/listinfo/dtn-interest Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.192]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j5A80bV20341 for ; Fri, 10 Jun 2005 01:00:37 -0700 Received: by zproxy.gmail.com with SMTP id 18so385485nzp for ; Fri, 10 Jun 2005 01:00:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MB0hpog1aSL+7POHlCip+bWZqm/7HQ2UHTAcxsJRiaFXRgONZpMSmBIXUsyXZlem2z0LHObxJ0XKzfu4k13KbAAUb5i4x2XLxBw/33w/L5UtEbSGTUkBRu65ZVfStLJurRmw00RVUjrte7nftWtYv0In9TGG+8C2/bE06WTwgUM= Received: by 10.36.106.17 with SMTP id e17mr982867nzc; Fri, 10 Jun 2005 01:00:31 -0700 (PDT) Received: by 10.36.38.19 with HTTP; Fri, 10 Jun 2005 01:00:31 -0700 (PDT) Message-ID: Date: Fri, 10 Jun 2005 09:00:31 +0100 From: Jeff Allen To: dtn-users@mailman.dtnrg.org Subject: Re: [dtn-users] Pinging example In-Reply-To: <20050610012126.57043.qmail@web60112.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050610012126.57043.qmail@web60112.mail.yahoo.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by webbie.berkeley.intel-research.net id j5A80bV20341 Sender: dtn-users-admin@mailman.dtnrg.org Errors-To: dtn-users-admin@mailman.dtnrg.org X-BeenThere: dtn-users@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-users@mailman.dtnrg.org X-Reply-To: jra@nella.org List-Unsubscribe: , List-Id: discussion/answers list for users of the dtn reference implementation List-Post: List-Help: List-Subscribe: , List-Archive: dtnping is a unix program that you need to run from the unix command prompt. All you can type at the "dtn%" command prompt are TCL commands. The "user interface" of DTN2 is a set of TCL commands that have been added to the usual interpreter. Type "help" to see what you can do there. -jeff Received: from web60112.mail.yahoo.com (web60112.mail.yahoo.com [209.73.178.95]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with SMTP id j5A1LbV18304 for ; Thu, 9 Jun 2005 18:21:37 -0700 Received: (qmail 57045 invoked by uid 60001); 10 Jun 2005 01:21:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Osy43tzk07avYT5VaXsHE3ToQj9rpE9qWBqaYHZNn599IoyJlFU2z3Sig8wO7is8uYFHfiAEWYWQW9fG2fifQQJdrcFYSqRxnGeYeFCW2oY+/Z+0ipCxjk3VWWhrlyVCYgDXRPUb+xmH09quoy42MyKi9z1qr3u+EPl4I1ThhDk= ; Message-ID: <20050610012126.57043.qmail@web60112.mail.yahoo.com> Received: from [130.85.94.92] by web60112.mail.yahoo.com via HTTP; Thu, 09 Jun 2005 18:21:26 PDT Date: Thu, 9 Jun 2005 18:21:26 -0700 (PDT) From: Yun To: dtn-users@mailman.dtnrg.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [dtn-users] Pinging example Sender: dtn-users-admin@mailman.dtnrg.org Errors-To: dtn-users-admin@mailman.dtnrg.org X-BeenThere: dtn-users@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-users@mailman.dtnrg.org List-Unsubscribe: , List-Id: discussion/answers list for users of the dtn reference implementation List-Post: List-Help: List-Subscribe: , List-Archive: When I test the pinging example, the dtnping command could not be found, but it's actually in the directory. Do I need to set up some environment variable? Following is the output: [root@ite351-pc-01 DTN2]# ./daemon/dtnd -c /home/yun/dtn/dtn.conf [1118366253.283717 /dtnd info] Bundle Daemon Initializing... [1118366253.283792 /dtnd info] random seed is 283789 [1118366253.290862 /dtnd info] parsing configuration file /home/yun/dtn/dtn.conf... [1118366253.325331 /dtnd info] dtnd parsing configuration... [1118366253.330381 /interface info] adding interface tcp host://0.0.0.0:5000/ [1118366253.400159 /interface info] adding interface udp host://0.0.0.0:6000/ [1118366253.400453 /dtnd info] dtnd configuration parsing complete [1118366253.406842 /storage/berkeleydb info] database file '/home/yun/dtn/db/DTN.db' validated [1118366253.495092 /tcl info] can't load tclreadline: can't find package tclreadline [1118366253.495253 /tcl info] fall back to simple command loop dtn% DTN2/apps/dtnping/dtnping bundles://internet/host://dtn-a error: invalid command name "DTN2/apps/dtnping/dtnping" while executing invalid command name "DTN2/apps/dtnping/dtnping" while executing "DTN2/apps/dtnping/dtnping bundles://internet/host://dtn-a" ("uplevel" body line 1) invoked from within "uplevel \#0 $command($input)" Thanks! -Yun __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j59MnfV17456 for ; Thu, 9 Jun 2005 15:49:42 -0700 Received: by wproxy.gmail.com with SMTP id 71so424696wri for ; Thu, 09 Jun 2005 15:49:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=P+B1Gl+CQG1kUtDpEZIJdpAWaJRK00JDbDf2/RwWhmPrLHQTRQYzpQKWQZ226moogi4q5tvBk+JYl79LsPnnfd2/g7HiqB+xLD4ds9xVSeXkL9HRTrYS2i7AV5a9EYrnZ88sOvYqod20ECkCnJ22gtRvvium4yzm4nB+dOkhEbE= Received: by 10.54.32.15 with SMTP id f15mr628128wrf; Thu, 09 Jun 2005 15:49:41 -0700 (PDT) Received: by 10.54.24.4 with HTTP; Thu, 9 Jun 2005 15:49:41 -0700 (PDT) Message-ID: <528fa01a05060915495b6bb24f@mail.gmail.com> Date: Thu, 9 Jun 2005 15:49:41 -0700 From: Melissa Ho To: dtn-users@mailman.dtnrg.org Subject: Re: [dtn-users] Configuration in DTN2 In-Reply-To: <20050609221808.41042.qmail@web60115.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20050609221808.41042.qmail@web60115.mail.yahoo.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by webbie.berkeley.intel-research.net id j59MnfV17456 Sender: dtn-users-admin@mailman.dtnrg.org Errors-To: dtn-users-admin@mailman.dtnrg.org X-BeenThere: dtn-users@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-users@mailman.dtnrg.org X-Reply-To: mrh9@cornell.edu List-Unsubscribe: , List-Id: discussion/answers list for users of the dtn reference implementation List-Post: List-Help: List-Subscribe: , List-Archive: Set the environmrent variable LD_LIBRARY_PATH to the location of libtcl8.4.so % export LD_LIBRARY_PATH=/home/yun/tcl/lib Melissa On 6/9/05, Yun wrote: > Hi, > I have trouble when configuring DTN2. > I followed the instructions here: > http://www.dtnrg.org/wiki/Dtn2Compilation > I was stuck at step 2 of "Running and Testing DTN2", > the following error is shown: > # ./daemon/dtnd -c ./daemon/dtn.conf --init-db > ./daemon/dtnd: error while loading shared libraries: > libtcl8.4.so: cannot open shared object file: No such > file or directory > > I have no idea what's wrong with it, since I think the > tcl, Berkeley-db, and DTN2 are installed successfully. > Is it a problem that I installed in wrong directories? > Here is my directory structure: > /home/yun/db-4.3.28.NC > /home/yun/DTN2 > /home/yun/tcl8.4.10 > and I set tcl to be installed in: > /home/yun/tcl > > Thanks! > > -Yun > > > > __________________________________ > Discover Yahoo! > Stay in touch with email, IM, photo sharing and more. Check it out! > http://discover.yahoo.com/stayintouch.html > _______________________________________________ > dtn-users mailing list > dtn-users@mailman.dtnrg.org > http://mailman.dtnrg.org/mailman/listinfo/dtn-users > Received: from web60115.mail.yahoo.com (web60115.mail.yahoo.com [209.73.178.98]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with SMTP id j59MIJV17270 for ; Thu, 9 Jun 2005 15:18:19 -0700 Received: (qmail 41044 invoked by uid 60001); 9 Jun 2005 22:18:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=jteCWzR7TO992z8qk2F2bSamTholMIrGtvYpmOEX1nsAPA4TJuI00dgrywD2+zi9MZL5I62xNheVj99wAKscKuDDCA2QvIxH+olpVVun+oKEWsKYkPabLJFb494tEcLZS4aA8m7BebTsVLhDqxQjIphyukEu/bTIyEJhMMAq/E8= ; Message-ID: <20050609221808.41042.qmail@web60115.mail.yahoo.com> Received: from [130.85.94.92] by web60115.mail.yahoo.com via HTTP; Thu, 09 Jun 2005 15:18:08 PDT Date: Thu, 9 Jun 2005 15:18:08 -0700 (PDT) From: Yun To: dtn-users@mailman.dtnrg.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [dtn-users] Configuration in DTN2 Sender: dtn-users-admin@mailman.dtnrg.org Errors-To: dtn-users-admin@mailman.dtnrg.org X-BeenThere: dtn-users@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-users@mailman.dtnrg.org List-Unsubscribe: , List-Id: discussion/answers list for users of the dtn reference implementation List-Post: List-Help: List-Subscribe: , List-Archive: Hi, I have trouble when configuring DTN2. I followed the instructions here: http://www.dtnrg.org/wiki/Dtn2Compilation I was stuck at step 2 of "Running and Testing DTN2", the following error is shown: # ./daemon/dtnd -c ./daemon/dtn.conf --init-db ./daemon/dtnd: error while loading shared libraries: libtcl8.4.so: cannot open shared object file: No such file or directory I have no idea what's wrong with it, since I think the tcl, Berkeley-db, and DTN2 are installed successfully. Is it a problem that I installed in wrong directories? Here is my directory structure: /home/yun/db-4.3.28.NC /home/yun/DTN2 /home/yun/tcl8.4.10 and I set tcl to be installed in: /home/yun/tcl Thanks! -Yun __________________________________ Discover Yahoo! Stay in touch with email, IM, photo sharing and more. Check it out! http://discover.yahoo.com/stayintouch.html Received: from masaka.cs.ohiou.edu (masaka.cs.ohiou.edu [132.235.3.154]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j58MGpV17515 for ; Wed, 8 Jun 2005 15:16:51 -0700 Received: from masaka.cs.ohiou.edu (localhost [127.0.0.1]) by masaka.cs.ohiou.edu (8.12.10+Sun/8.12.8) with ESMTP id j58MGivP021084; Wed, 8 Jun 2005 18:16:44 -0400 (EDT) Received: (from mramadas@localhost) by masaka.cs.ohiou.edu (8.12.10+Sun/8.12.10/Submit) id j58MGaKn021083; Wed, 8 Jun 2005 18:16:36 -0400 (EDT) Date: Wed, 8 Jun 2005 18:16:36 -0400 From: Manikantan Ramadas To: demmer@cs.berkeley.edu Cc: dtn-users@mailman.dtnrg.org, 644@masaka.cs.ohiou.edu Message-ID: <20050608221636.GA20213@masaka.cs.ohiou.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5/uDoXvLw7AC5HRs" Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [dtn-users] Running DTN2 on Solaris/Fedora - feedback Sender: dtn-users-admin@mailman.dtnrg.org Errors-To: dtn-users-admin@mailman.dtnrg.org X-BeenThere: dtn-users@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-users@mailman.dtnrg.org List-Unsubscribe: , List-Id: discussion/answers list for users of the dtn reference implementation List-Post: List-Help: List-Subscribe: , List-Archive: --5/uDoXvLw7AC5HRs Content-Type: multipart/mixed; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Mike and other DTN2-users, We played around with the DTN2 implementation recently in our Networking Seminar class here at Ohio University. We ran into some issues getting it compiled under Solaris 10 / gcc 3.4.1. After a little bit of agony however, we got it to compile and run under Solaris. I am sending the patches we made to get it to work (diff -c output) in the attached file DTN2-2-Jun-2005-diffs. These patches were made (obviously) against the DTN2 code checked out as per 2 Jun 2005. I planned to send the patches with the current cutting edge DTN2 code, but had the same compilation problems mentioned in a recent mail with respect to module initialization sequences on various oasys modules. It could be a gcc-3.4.x problem in understanding macros taking variable number of arguments. I couldn't figure out the problem in the 1/2 hour I spent on it, and hence reverted back to a version before the current flux.=20 Most of the patches (as you may find) are trivial - adding in a header file here, fixing a header file there, etc. The correct solution for some of them could be a little bit non-trivial and may need tinkering of the configure scripts. For example - net/ethernet.h on Fedora exists as sys/ethernet.h on Solaris; u_int32_t on Fedora is uint32_t on Solaris etc. But other patches, I think may be safely applied, and shouldn't take long. In our experiments, the dtn end-applications running on Solaris boxes bounced their data through a fedora-based testbed where we emulated sample ISS, Moon, and Mars space links. We were wondering whether TCP could be coerced into transfering data across these links [despite all the reasons why TCP is a bad-choice on deep-space links as outlined in our LTP motivation draft :-) ]. We found that in Fedora, one needs to tweak up tcp_syn_retries and tcp_synack_retries variables in the sender and receiver side-s respectively, under /proc/sys/net/ipv4/. By default, both these variables have the value 5, which amounts to TCP giving up on a connection in approximately 3 minutes, which didn't work across our emulated mars-link with 20Kbps bandwidth, 8 minute RTT. We set them both, without thinking too much :-), to the maximum allowed value of 255 each to get it to work.=20 Attached with this mail is the throughput-graph generated on this Mars link. - Mani. PS : Please ignore the fact that X-axis in the graph is not in any scale, as it is purely for illustrative purposes. --=20 "'Beauty is truth, truth beauty,'--that is all Ye know on earth, and all ye need to know." - John Keats ____________________________________________________________________ =20 * Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas * ____________________________________________________________________ --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=DTN2-2-Jun-2005-diffs Content-Transfer-Encoding: quoted-printable Script started on Wed Jun 08 17:15:17 2005=0D p1:/home/mramadas/dtn/DTN2-2-Jun-2005> diff -c oasys/io/FileIOClient.cc-ori= g oasys/io/FileIOClient.cc=0D *** oasys/io/FileIOClient.cc-orig Wed Jun 8 16:49:25 2005=0D --- oasys/io/FileIOClient.cc Wed Jun 8 16:49:47 2005=0D ***************=0D *** 35,41 ****=0D * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE= =0D * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.=0D */=0D ! =0D #include =0D #include "FileIOClient.h"=0D #include "IO.h"=0D --- 35,41 ----=0D * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE= =0D * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.=0D */=0D ! #include =0D #include =0D #include "FileIOClient.h"=0D #include "IO.h"=0D =0D p1:/home/mramadas/dtn/DTN2-2-Jun-2005> diff -c oasys/storage/BerkeleyDBStor= e.cc-orig oasys/storage/BerkeleyDBStore.cc=0D *** oasys/storage/BerkeleyDBStore.cc-orig Wed Jun 8 16:53:44 2005=0D --- oasys/storage/BerkeleyDBStore.cc Wed Jun 8 16:50:51 2005=0D ***************=0D *** 40,46 ****=0D #include =0D #include =0D #include =0D ! =0D #include =0D #include =0D #include =0D --- 40,46 ----=0D #include =0D #include =0D #include =0D ! #include =0D #include =0D #include =0D #include =0D =0D p1:/home/mramadas/dtn/DTN2-2-Jun-2005> diff -c oasys/util/Getopt.cc-orig oa= sys/util/Getopt.cc=0D *** oasys/util/Getopt.cc-orig Wed Jun 8 16:53:24 2005=0D --- oasys/util/Getopt.cc Wed Jun 8 16:52:01 2005=0D ***************=0D *** 96,102 ****=0D }=0D =0D if (opt->longopt_) {=0D ! long_opts[i].name =3D opt->longopt_;=0D long_opts[i].has_arg =3D opt->needval_;=0D } else {=0D // ignore this slot=0D --- 96,102 ----=0D }=0D =0D if (opt->longopt_) {=0D ! long_opts[i].name =3D (char*) opt->longopt_;=0D long_opts[i].has_arg =3D opt->needval_;=0D } else {=0D // ignore this slot=0D =0D p1:/home/mramadas/dtn/DTN2-2-Jun-2005> diff -c applib/dtn_ipc.h-orig applib= /dtn_ipc.h=0D *** applib/dtn_ipc.h-orig Wed Jun 8 16:58:02 2005=0D --- applib/dtn_ipc.h Wed Jun 8 16:58:17 2005=0D ***************=0D *** 99,105 ****=0D /**=0D * Type code to string conversion routine.=0D */=0D ! const char* dtnipc_msgtoa(u_int32_t type);=0D =0D /*=0D * Initialize the handle structure and a new ipc session with the=0D --- 99,105 ----=0D /**=0D * Type code to string conversion routine.=0D */=0D ! const char* dtnipc_msgtoa(uint32_t type);=0D =0D /*=0D * Initialize the handle structure and a new ipc session with the=0D =0D p1:/home/mramadas/dtn/DTN2-2-Jun-2005> diff -c servlib/bundling/EthernetAdd= ressFamily.h-orig servlib/bundling/EthernetAddressFamily.h=0D *** servlib/bundling/EthernetAddressFamily.h-orig Wed Jun 8 17:04:31= 2005=0D --- servlib/bundling/EthernetAddressFamily.h Wed Jun 8 17:07:47 2005=0D ***************=0D *** 41,56 ****=0D #include "AddressFamily.h"=0D #include =0D #include =0D ! #include =0D #include =0D =0D namespace dtn {=0D =0D ! //#define ETH_ADDR_LEN 6=0D =0D =0D typedef struct ether_addr {=0D ! u_char octet[ETHER_ADDR_LEN];=0D } eth_addr_t; =0D =0D /**=0D --- 41,56 ----=0D #include "AddressFamily.h"=0D #include =0D #include =0D ! #include =0D #include =0D =0D namespace dtn {=0D =0D ! #define ETH_ADDR_LEN 6=0D =0D =0D typedef struct ether_addr {=0D ! u_char octet[ETH_ADDR_LEN];=0D } eth_addr_t; =0D =0D /**=0D =0D p1:/home/mramadas/dtn/DTN2-2-Jun-2005> diff -c apps/dtnping/dtnping.c-orig = apps/dtnping/dtnping.c=0D *** apps/dtnping/dtnping.c-orig Wed Jun 8 17:12:32 2005=0D --- apps/dtnping/dtnping.c Wed Jun 8 17:12:54 2005=0D ***************=0D *** 110,116 ****=0D // if the user specified a source tuple, register on it.=0D // otherwise, build a local tuple based on the configuration of=0D // our dtn router plus the demux string=0D ! snprintf(demux, sizeof(demux), "/ping.%d", getpid());=0D if (source_tuple_str[0] !=3D '\0') {=0D if (dtn_parse_tuple_string(&source_tuple, source_tuple_str)) {=0D fprintf(stderr, "invalid source tuple string '%s'\n",=0D --- 110,116 ----=0D // if the user specified a source tuple, register on it.=0D // otherwise, build a local tuple based on the configuration of=0D // our dtn router plus the demux string=0D ! snprintf(demux, sizeof(demux), "/ping.%d", (int) getpid());=0D if (source_tuple_str[0] !=3D '\0') {=0D if (dtn_parse_tuple_string(&source_tuple, source_tuple_str)) {=0D fprintf(stderr, "invalid source tuple string '%s'\n",=0D p1:/home/mramadas/dtn/DTN2-2-Jun-2005>=0D =0D script done on Wed Jun 08 17:20:34 2005=0D --k+w/mQv8wyuph6w0 Content-Type: application/pdf Content-Disposition: attachment; filename="mars-expt.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjQNJeLjz9MNCjYgMCBvYmo8PC9IWzU1NiAxNDZdL0xpbmVhcml6ZWQgMS9FIDU4 ODkvTCA5ODA5L04gMS9PIDkvVCA5NjQzPj4NZW5kb2JqDSAgICAgICAgICAgICAgICAgICAg ICAgICAgDQp4cmVmDQo2IDEzDQowMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMDA3MDIgMDAw MDAgbg0KMDAwMDAwMDU1NiAwMDAwMCBuDQowMDAwMDAwNzc4IDAwMDAwIG4NCjAwMDAwMDA5 MDYgMDAwMDAgbg0KMDAwMDAwMTAyNyAwMDAwMCBuDQowMDAwMDAxOTg1IDAwMDAwIG4NCjAw MDAwMDIwMTkgMDAwMDAgbg0KMDAwMDAwMjQxMyAwMDAwMCBuDQowMDAwMDAyNjk2IDAwMDAw IG4NCjAwMDAwMDUzNjUgMDAwMDAgbg0KMDAwMDAwNTU5MiAwMDAwMCBuDQowMDAwMDA1ODEz IDAwMDAwIG4NCnRyYWlsZXINCjw8L1NpemUgMTkvUHJldiA5NjMzL1Jvb3QgNyAwIFIvSW5m byA1IDAgUi9JRFs8ZGRkNjRhZjBiN2UzMzQ4OWZjMWFiZGVmYWQ2YWM0ZDU+PDNlZWEzOGUz NmI4OGRhNGFiYWNkY2YxNTI3YzAyYjc5Pl0+Pg0Kc3RhcnR4cmVmDQowDQolJUVPRg0KICAg ICAgICAgICAgICAgICANCjggMCBvYmo8PC9MZW5ndGggNjkvRmlsdGVyL0ZsYXRlRGVjb2Rl L0wgODAvUyAzOT4+c3RyZWFtDQp42mJgYOBiYGCqYAAC4e8MqIAJiFkYOA6YJiAJckExA4MS Aw/rg3DLAwxiDT+XbDjIvUELLMzIwCCWD9VtARBgAJLbCrINCmVuZHN0cmVhbQ1lbmRvYmoN NyAwIG9iajw8L1BhZ2VzIDMgMCBSL1R5cGUvQ2F0YWxvZy9QYWdlTGFiZWxzIDEgMCBSL01l dGFkYXRhIDQgMCBSPj4NZW5kb2JqDTkgMCBvYmo8PC9Db250ZW50cyAxMSAwIFIvVHlwZS9Q YWdlL1BhcmVudCAzIDAgUi9Sb3RhdGUgOTAvTWVkaWFCb3hbMCAwIDYxMiA3OTJdL0Nyb3BC b3hbMCAwIDYxMiA3OTJdL1Jlc291cmNlcyAxMCAwIFI+Pg1lbmRvYmoNMTAgMCBvYmo8PC9D b2xvclNwYWNlPDwvQ3M2IDEyIDAgUj4+L0ZvbnQ8PC9UVDIgMTMgMCBSL1RUNCAxNCAwIFI+ Pi9Qcm9jU2V0Wy9QREYvVGV4dF0vRXh0R1N0YXRlPDwvR1MxIDE4IDAgUj4+Pj4NZW5kb2Jq DTExIDAgb2JqPDwvTGVuZ3RoIDg4OS9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImk VctuE0sQ3fdX1NJBcqff070lPCS4IK48gkVgQYITDDM2NxOE4OtvVU8/poPZYEXOdPnU89Tp seCdVcHALTt/vpFwOzGpBQ8epNBcGtDWcQlOKTLutuyG/cck7IAZ7bjKXoILGwJGVcd3sGcC nqPzC5DwhVwc/MAAeAWXHwR8ajOMyeyU5crDwDbs31xKe8v1abXaFGO2j1bThhtzWrUmxZjt Y9WU19ydNlubYsz20Wpa8e602doUY7aPVZNecu9OqtamGLN9tFqj27+r1qQYs91UE9wKGVzK I2Ke8DBPvCC+46IEr+eLtK7ttMlHNsXmUlO/tZKyJXuotqDHETxdrgwv79pQr0OC2+sxVAFn vBH0UCWX8FaCQxVJxhvRDHWtCW/XPNTpM96wMTyYdnzANeJBEPBn9hIe1AJEoyDKY8EFmOyC axd4t+A92QU31nO3qJzsglvTcVvh2Syow22ZRfVkF7xo5uHcG3Z+MTm42KAw8S9JdXPxmskq VGac4g7ZxqKOkkh6KqrhaPc2KlSrKAm0VeAaJ5KGq3n3jnZhicu46sAFDhQkZcfV2YDZHPLl Ve3oemo6mq732MW8g9xFasrit3FUZ7n0CR5qz5YGHtrogV09wjEilOaoY3nqFgNUTFzGzLDm Ie6liY4JtQkk6kTEWInpuI+XxBpqqRKVccWpYBs+Z1SOWElUjpVax7tIvY7XoFBdcMm7eRXL +JhSeUMNz9sY63Is1aZlBRRW2VVGcQ8+2ovgOR3Ob1Xe5li3i44xwkhuXd12xrGMmS/+Mj6m lHbW8KyIsQhE02ioF1ws7qUIJsGd5zpay+CY73HPzvseXzbQ3+ArE2PX+BEQkCtQztMO+hGR W/z01/TvB1u9GQ73cLiBZ7thC5vdry28naD/fHf4fvv523eE9vDq490E/+z2X8/6L1TClBL4 FqIq8SEgXcIgqMxKkPcaCbUuAGqow9dA/4StZAT6R2ylyknHk4huMkQ3s/gqRdri78qpiyfL 0cfgbwmuEVWLzpcr+fVs3XmJJK50PXZ0tOjXYSN0VtatpM0nRScXkFWLODp86F8sWFWoN4G/ Q2t6osSpq0rc+9VuDy93wwGuft5vp/dnkYHMjshEaXw3oWY6/E9EIUVCoGppGQveY7Kr3f0E 37Z3MG2vD/tPKeXTnv0vwADKCilfCg0KZW5kc3RyZWFtDWVuZG9iag0xMiAwIG9ialsvSUND QmFzZWQgMTUgMCBSXQ1lbmRvYmoNMTMgMCBvYmo8PC9UeXBlL0ZvbnQvRW5jb2RpbmcvV2lu QW5zaUVuY29kaW5nL0Jhc2VGb250L0FyaWFsLUJvbGRNVC9GaXJzdENoYXIgMzIvTGFzdENo YXIgMTIyL1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0b3IgMTYgMCBSL1dpZHRoc1sy NzggMCAwIDAgMCAwIDAgMCAzMzMgMzMzIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNjExIDAgMCAwIDAgNzIyIDYxMSA4MzMgMCAw IDY2NyAwIDAgNjY3IDYxMSAwIDY2NyAwIDAgMCAwIDAgMCAwIDAgMCAwIDU1NiA2MTEgNTU2 IDYxMSA1NTYgMzMzIDYxMSA2MTEgMjc4IDAgNTU2IDI3OCAwIDYxMSA2MTEgNjExIDAgMzg5 IDU1NiAzMzMgNjExIDAgMCAwIDU1NiA1MDBdPj4NZW5kb2JqDTE0IDAgb2JqPDwvVHlwZS9G b250L0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9CYXNlRm9udC9BcmlhbE1UL0ZpcnN0Q2hh ciA0OC9MYXN0Q2hhciAxMDcvU3VidHlwZS9UcnVlVHlwZS9Gb250RGVzY3JpcHRvciAxNyAw IFIvV2lkdGhzWzU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTAwXT4+DWVuZG9iag0xNSAw IG9iajw8L0xlbmd0aCAyNTc1L0ZpbHRlci9GbGF0ZURlY29kZS9OIDMvQWx0ZXJuYXRlL0Rl dmljZVJHQj4+c3RyZWFtDQpIiZyWeVRTdxbHf2/JnpCVsMNjDVuAsAaQNWxhkR0EUQhJCAES QkjYBUFEBRRFRISqlTLWbXRGT0WdLq5jrQ7WferSA/Uw6ug4tBbXjp0XOEedTmem0+8f7/c5 93fv793fvfed8wCgJ6WqtdUwCwCN1qDPSozFFhUUYqQJAAMKIAIRADJ5rS4tOyEH4JLGS7Ba 3An8i55eB5BpvSJMysAw8P+JLdfpDQBAGTgHKJS1cpw7ca6qN+hM9hmceaWVJoZRE+vxBHG2 NLFqnr3nfOY52sQKjVaBsylnnUKjMPFpnFfXGZU4I6k4d9WplfU4X8XZpcqoUeP83BSrUcpq AUDpJrtBKS/H2Q9nuj4nS4LzAgDIdNU7XPoOG5QNBtOlJNW6Rr1aVW7A3OUemCg0VIwlKeur lAaDMEMmr5TpFZikWqOTaRsBmL/znDim2mJ4kYNFocHBQn8f0TuF+q+bv1Cm3s7Tk8y5nkH8 C29tP+dXPQqAeBavzfq3ttItAIyvBMDy5luby/sAMPG+Hb74zn34pnkpNxh0Yb6+9fX1Pmql 3MdU0Df6nw6/QO+8z8d03JvyYHHKMpmxyoCZ6iavrqo26rFanUyuxIQ/HeJfHfjzeXhnKcuU eqUWj8jDp0ytVeHt1irUBnW1FlNr/1MTf2XYTzQ/17i4Y68Br9gHsC7yAPK3CwDl0gBStA3f gd70LZWSBzLwNd/h3vzczwn691PhPtOjVq2ai5Nk5WByo75ufs/0WQICoAIm4AErYA+cgTsQ An8QAsJBNIgHySAd5IACsBTIQTnQAD2oBy2gHXSBHrAebALDYDsYA7vBfnAQjIOPwQnwR3Ae fAmugVtgEkyDh2AGPAWvIAgiQQyIC1lBDpAr5AX5Q2IoEoqHUqEsqAAqgVSQFjJCLdAKqAfq h4ahHdBu6PfQUegEdA66BH0FTUEPoO+glzAC02EebAe7wb6wGI6BU+AceAmsgmvgJrgTXgcP waPwPvgwfAI+D1+DJ+GH8CwCEBrCRxwRISJGJEg6UoiUIXqkFelGBpFRZD9yDDmLXEEmkUfI C5SIclEMFaLhaBKai8rRGrQV7UWH0V3oYfQ0egWdQmfQ1wQGwZbgRQgjSAmLCCpCPaGLMEjY SfiIcIZwjTBNeEokEvlEATGEmEQsIFYQm4m9xK3EA8TjxEvEu8RZEolkRfIiRZDSSTKSgdRF 2kLaR/qMdJk0TXpOppEdyP7kBHIhWUvuIA+S95A/JV8m3yO/orAorpQwSjpFQWmk9FHGKMco FynTlFdUNlVAjaDmUCuo7dQh6n7qGept6hMajeZEC6Vl0tS05bQh2u9on9OmaC/oHLonXUIv ohvp6+gf0o/Tv6I/YTAYboxoRiHDwFjH2M04xfia8dyMa+ZjJjVTmLWZjZgdNrts9phJYboy Y5hLmU3MQeYh5kXmIxaF5caSsGSsVtYI6yjrBmuWzWWL2OlsDbuXvYd9jn2fQ+K4ceI5Ck4n 5wPOKc5dLsJ15kq4cu4K7hj3DHeaR+QJeFJeBa+H91veBG/GnGMeaJ5n3mA+Yv6J+SQf4bvx pfwqfh//IP86/6WFnUWMhdJijcV+i8sWzyxtLKMtlZbdlgcsr1m+tMKs4q0qrTZYjVvdsUat Pa0zreutt1mfsX5kw7MJt5HbdNsctLlpC9t62mbZNtt+YHvBdtbO3i7RTme3xe6U3SN7vn20 fYX9gP2n9g8cuA6RDmqHAYfPHP6KmWMxWBU2hJ3GZhxtHZMcjY47HCccXzkJnHKdOpwOON1x pjqLncucB5xPOs+4OLikubS47HW56UpxFbuWu252Pev6zE3glu+2ym3c7b7AUiAVNAn2Cm67 M9yj3GvcR92vehA9xB6VHls9vvSEPYM8yz1HPC96wV7BXmqvrV6XvAneod5a71HvG0K6MEZY J9wrnPLh+6T6dPiM+zz2dfEt9N3ge9b3tV+QX5XfmN8tEUeULOoQHRN95+/pL/cf8b8awAhI CGgLOBLwbaBXoDJwW+Cfg7hBaUGrgk4G/SM4JFgfvD/4QYhLSEnIeyE3xDxxhrhX/HkoITQ2 tC3049AXYcFhhrCDYX8PF4ZXhu8Jv79AsEC5YGzB3QinCFnEjojJSCyyJPL9yMkoxyhZ1GjU N9HO0YrondH3YjxiKmL2xTyO9YvVx34U+0wSJlkmOR6HxCXGdcdNxHPic+OH479OcEpQJexN mEkMSmxOPJ5ESEpJ2pB0Q2onlUt3S2eSQ5KXJZ9OoadkpwynfJPqmapPPZYGpyWnbUy7vdB1 oXbheDpIl6ZvTL+TIcioyfhDJjEzI3Mk8y9ZoqyWrLPZ3Ozi7D3ZT3Nic/pybuW65xpzT+Yx 84ryduc9y4/L78+fXOS7aNmi8wXWBeqCI4WkwrzCnYWzi+MXb1o8XRRU1FV0fYlgScOSc0ut l1Yt/aSYWSwrPlRCKMkv2VPygyxdNiqbLZWWvlc6I5fIN8sfKqIVA4oHyghlv/JeWURZf9l9 VYRqo+pBeVT5YPkjtUQ9rP62Iqlie8WzyvTKDyt/rMqvOqAha0o0R7UcbaX2dLV9dUP1JZ2X rks3WRNWs6lmRp+i31kL1S6pPWLg4T9TF4zuxpXGqbrIupG65/V59Yca2A3ahguNno1rGu81 JTT9phltljefbHFsaW+ZWhazbEcr1FraerLNua2zbXp54vJd7dT2yvY/dfh19Hd8vyJ/xbFO u87lnXdXJq7c22XWpe+6sSp81fbV6Gr16ok1AWu2rHndrej+osevZ7Dnh1557xdrRWuH1v64 rmzdRF9w37b1xPXa9dc3RG3Y1c/ub+q/uzFt4+EBbKB74PtNxZvODQYObt9M3WzcPDmU+k8A pAFb/pi4mSSZkJn8mmia1ZtCm6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMG o3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8W r4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7Lrun vCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8 yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV 1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4DbgveFE4cziU+Lb42Pj6+Rz 5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M8Fjw5fFy8f/yjPMZ 86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23//wIMAPeE8/sK DQplbmRzdHJlYW0NZW5kb2JqDTE2IDAgb2JqPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250 QkJveFstNjI4IC0zNzYgMjAwMCAxMDEwXS9Gb250TmFtZS9BcmlhbC1Cb2xkTVQvRmxhZ3Mg MzIvU3RlbVYgMTM4L0NhcEhlaWdodCA3MTgvWEhlaWdodCA1MTUvQXNjZW50IDkwNS9EZXNj ZW50IC0yMTEvSXRhbGljQW5nbGUgMC9Gb250RmFtaWx5KEFyaWFsKS9Gb250U3RyZXRjaC9O b3JtYWwvRm9udFdlaWdodCA3MDA+Pg1lbmRvYmoNMTcgMCBvYmo8PC9UeXBlL0ZvbnREZXNj cmlwdG9yL0ZvbnRCQm94Wy02NjUgLTMyNSAyMDAwIDEwMDZdL0ZvbnROYW1lL0FyaWFsTVQv RmxhZ3MgMzIvU3RlbVYgODgvQ2FwSGVpZ2h0IDcxOC9YSGVpZ2h0IDUxNS9Bc2NlbnQgOTA1 L0Rlc2NlbnQgLTIxMS9JdGFsaWNBbmdsZSAwL0ZvbnRGYW1pbHkoQXJpYWwpL0ZvbnRTdHJl dGNoL05vcm1hbC9Gb250V2VpZ2h0IDQwMD4+DWVuZG9iag0xOCAwIG9iajw8L1R5cGUvRXh0 R1N0YXRlL1NBIGZhbHNlL09QIGZhbHNlL1NNIDAuMDIvb3AgZmFsc2UvT1BNIDE+Pg1lbmRv YmoNMSAwIG9iajw8L051bXNbMCAyIDAgUl0+Pg1lbmRvYmoNMiAwIG9iajw8L1MvRD4+DWVu ZG9iag0zIDAgb2JqPDwvQ291bnQgMS9LaWRzWzkgMCBSXS9UeXBlL1BhZ2VzPj4NZW5kb2Jq DTQgMCBvYmo8PC9MZW5ndGggMzM1OC9UeXBlL01ldGFkYXRhL1N1YnR5cGUvWE1MPj5zdHJl YW0NCjw/eHBhY2tldCBiZWdpbj0n77u/JyBpZD0nVzVNME1wQ2VoaUh6cmVTek5UY3prYzlk Jz8+Cjw/YWRvYmUteGFwLWZpbHRlcnMgZXNjPSJDUkxGIj8+DQo8eDp4bXBtZXRhIHhtbG5z Ong9J2Fkb2JlOm5zOm1ldGEvJyB4OnhtcHRrPSdYTVAgdG9vbGtpdCAyLjkuMS0xMywgZnJh bWV3b3JrIDEuNic+DQo8cmRmOlJERiB4bWxuczpyZGY9J2h0dHA6Ly93d3cudzMub3JnLzE5 OTkvMDIvMjItcmRmLXN5bnRheC1ucyMnIHhtbG5zOmlYPSdodHRwOi8vbnMuYWRvYmUuY29t L2lYLzEuMC8nPg0KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9J3V1aWQ6NjAxY2E1NDQt OTViMC00YTkwLWIwMzUtMTJjNDNmY2IxOTM3JyB4bWxuczpwZGY9J2h0dHA6Ly9ucy5hZG9i ZS5jb20vcGRmLzEuMy8nIHBkZjpQcm9kdWNlcj0nQWNyb2JhdCBEaXN0aWxsZXIgNi4wIChX aW5kb3dzKSc+PC9yZGY6RGVzY3JpcHRpb24+DQo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91 dD0ndXVpZDo2MDFjYTU0NC05NWIwLTRhOTAtYjAzNS0xMmM0M2ZjYjE5MzcnIHhtbG5zOnhh cD0naHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLycgeGFwOkNyZWF0b3JUb29sPSdBY3Jv YmF0IFBERk1ha2VyIDYuMCBmb3IgRXhjZWwnIHhhcDpNb2RpZnlEYXRlPScyMDA1LTA2LTA2 VDExOjU3OjQwLTA0OjAwJyB4YXA6Q3JlYXRlRGF0ZT0nMjAwNS0wNi0wNlQxMTo1NzoxMi0w NDowMCcgeGFwOk1ldGFkYXRhRGF0ZT0nMjAwNS0wNi0wNlQxMTo1Nzo0MC0wNDowMCc+PC9y ZGY6RGVzY3JpcHRpb24+DQo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0ndXVpZDo2MDFj YTU0NC05NWIwLTRhOTAtYjAzNS0xMmM0M2ZjYjE5MzcnIHhtbG5zOnhhcE1NPSdodHRwOi8v bnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vJyB4YXBNTTpEb2N1bWVudElEPSd1dWlkOjM0YmYz YzAxLTJiYWMtNGU2OS1hOGE1LTQ1NDBmYzc3ZDRhNicvPg0KPHJkZjpEZXNjcmlwdGlvbiBy ZGY6YWJvdXQ9J3V1aWQ6NjAxY2E1NDQtOTViMC00YTkwLWIwMzUtMTJjNDNmY2IxOTM3JyB4 bWxuczpkYz0naHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8nIGRjOmZvcm1hdD0n YXBwbGljYXRpb24vcGRmJz48ZGM6dGl0bGU+PHJkZjpBbHQ+PHJkZjpsaSB4bWw6bGFuZz0n eC1kZWZhdWx0Jz5tYXJzLWV4cHQueGxzPC9yZGY6bGk+PC9yZGY6QWx0PjwvZGM6dGl0bGU+ PGRjOmNyZWF0b3I+PHJkZjpTZXE+PHJkZjpsaT48L3JkZjpsaT48L3JkZjpTZXE+PC9kYzpj cmVhdG9yPjwvcmRmOkRlc2NyaXB0aW9uPg0KPC9yZGY6UkRGPg0KPC94OnhtcG1ldGE+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgCjw/eHBh Y2tldCBlbmQ9J3cnPz4NCmVuZHN0cmVhbQ1lbmRvYmoNNSAwIG9iajw8L01vZERhdGUoRDoy MDA1MDYwNjExNTc0MC0wNCcwMCcpL0NyZWF0aW9uRGF0ZShEOjIwMDUwNjA2MTE1NzEyLTA0 JzAwJykvVGl0bGUobWFycy1leHB0LnhscykvQ3JlYXRvcihBY3JvYmF0IFBERk1ha2VyIDYu MCBmb3IgRXhjZWwpL0F1dGhvcigpL1Byb2R1Y2VyKEFjcm9iYXQgRGlzdGlsbGVyIDYuMCBc KFdpbmRvd3NcKSk+Pg1lbmRvYmoNeHJlZg0KMCA2DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw MDAwMDU4ODkgMDAwMDAgbg0KMDAwMDAwNTkyMiAwMDAwMCBuDQowMDAwMDA1OTQ1IDAwMDAw IG4NCjAwMDAwMDU5OTUgMDAwMDAgbg0KMDAwMDAwOTQyOSAwMDAwMCBuDQp0cmFpbGVyDQo8 PC9TaXplIDY+Pg0Kc3RhcnR4cmVmDQoxMTYNCiUlRU9GDQo= --k+w/mQv8wyuph6w0-- --5/uDoXvLw7AC5HRs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (SunOS) iD8DBQFCp25DOxoMRRosfTURAie2AJ0SQQMHMwuNmJ3tRChcdN/WfeR3oQCeM7Lo vBoIjXfcfEGMAzDuQgRfdI4= =WpOw -----END PGP SIGNATURE----- --5/uDoXvLw7AC5HRs-- Received: from pisco (pisco.CS.Berkeley.EDU [128.32.37.175]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j58M0cV11567 for ; Wed, 8 Jun 2005 15:00:38 -0700 Received: from demmer by pisco with local (Exim 4.50) id 1Dg8bG-0007nS-1z for dtn-users@mailman.dtnrg.org; Wed, 08 Jun 2005 15:00:38 -0700 Date: Wed, 8 Jun 2005 15:00:38 -0700 From: Michael Demmer To: dtn-users@mailman.dtnrg.org Subject: Re: [dtn-users] Compilation and Installation problem with the latest DTN2 CVS Message-ID: <20050608220038.GN22270@pisco.cs.berkeley.edu> References: <1118080571.42a48e3b2bd7b@webmail.mail.gatech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1118080571.42a48e3b2bd7b@webmail.mail.gatech.edu> User-Agent: Mutt/1.4.2i Sender: dtn-users-admin@mailman.dtnrg.org Errors-To: dtn-users-admin@mailman.dtnrg.org X-BeenThere: dtn-users@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-users@mailman.dtnrg.org List-Unsubscribe: , List-Id: discussion/answers list for users of the dtn reference implementation List-Post: List-Help: List-Subscribe: , List-Archive: Sorry about the lag in replying. Given that you've had problems with both the 2.1.1 version and the current CVS version, then I would support your instinct that the problem is due to the installation problems of both tclreadline and berkeley db. One thing to try is to add the relevant lib directories to /etc/ld.so.conf and rerun ldconfig. That should (I think) fix the berkeley db problems. The tclreadline problems appear to be due to a missing installation of the dependent readline library. Good luck, -m > hi, > > I am trying to run the DTN2 code on Mandrake 9.2 Linux (HaCom OpenBrick mini > PC): > gcc 3.3.1, tcl8.4.9, BerkeleyDB.4.3, tclreadline-2.1.0, > > I used the latest CVS and found the following problem during compiling: > > in these two files > DTN2/daemon/dtnd.cc > DTN2/sim/dtnsim.cc > > oasys::TclCommandInterp::init(argv[0]); caused the error since the > TclCommandInterp::init() has been modified in the TclCommand.cc/h > (DTN2/oasys/tclcmd) compared to the previous version (in DTN-2.1.1.tgz as > TclCommandInterp::init(char* objv0, bool no_default_cmds = false) ) > > I changed the oasys::TclCommandInterp::init(argv[0]); to > oasys::TclCommandInterp::init(); and the compilation finished successfully. > > When I tried "dtnd -t", I got the following messages: > > couldn't load file "/usr/lib/libtclreadline.so": libreadline.so.5: cannot open > shared object file: NO such file or directory > > But this particular file is at /usr/lib/libtclreadline.so", which is a link to > libtclreadline-2.1.0.so in the same directory. > > The following error occurs during "make install": > > error while loading shared libraries: libdb_cxx-4.3.so > > However, this file exists at /usr/local/BerkeleyDB.4.3/lib/ and this directory > has been added to LD_LIBRARY_PATH. And I configured the BerkeleyDB with the -- > enable-cxx option. > > So I turned back to DTN-2.1.1.tgz version following the same procedure: > unzip > sh configure -C > make > > there is no compilation issue but the errors during install or dtnd -t are > still there. > > Personally, I think there might be some issues with the tclreadline and > BerkeleyDB installation. However, I followed the standard configure->make- > >make install procedure as a root. No error occurs. > > Thx for attention and any information is appreciated. > > -Yang > _______________________________________________ > dtn-users mailing list > dtn-users@mailman.dtnrg.org > http://mailman.dtnrg.org/mailman/listinfo/dtn-users Received: from pisco (pisco.CS.Berkeley.EDU [128.32.37.175]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j58KS1V05207; Wed, 8 Jun 2005 13:28:01 -0700 Received: from demmer by pisco with local (Exim 4.50) id 1Dg79d-0007YL-3w; Wed, 08 Jun 2005 13:28:01 -0700 Date: Wed, 8 Jun 2005 13:28:01 -0700 From: Michael Demmer To: Jeff Wilson Cc: dtn-bugs@mailman.dtnrg.org, dtn-users@mailman.dtnrg.org, Bowei Du Message-ID: <20050608202801.GK22270@pisco.cs.berkeley.edu> References: <5f30e26105060811394a4bd44a@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5f30e26105060811394a4bd44a@mail.gmail.com> User-Agent: Mutt/1.4.2i Subject: [dtn-users] Re: [dtn-bugs] error compiling CVS code Sender: dtn-users-admin@mailman.dtnrg.org Errors-To: dtn-users-admin@mailman.dtnrg.org X-BeenThere: dtn-users@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-users@mailman.dtnrg.org List-Unsubscribe: , List-Id: discussion/answers list for users of the dtn reference implementation List-Post: List-Help: List-Subscribe: , List-Archive: The version in the CVS repository has been undergoing some flux in recent days related to some new refactoring of the initialization sequence. We expect that this and the other identified problems will be fixed within a week or so. In the meantime, this particular problem only shows up with gcc 3.4 so you could try downgrading your compiler or just backing out to the version from a couple weeks ago. -m > Hi all, > > I ran `cvs up -Pd` for the first time in a while, then got the > following error after `configure -C && make`: > > g++ -I. -g -fno-inline -MMD -MP -MT "storage/BerkeleyDBStore.o > storage/BerkeleyDBStore.E storage/BerkeleyDBStore.po" -Wall -Werror > -c storage/BerkeleyDBStore.cc -o storage/BerkeleyDBStore.o > storage/BerkeleyDBStore.cc:70: error: too few template-parameter-lists > storage/BerkeleyDBStore.cc:70: error: expected `,' or `;' before '=' token > make[1]: *** [storage/BerkeleyDBStore.o] Error 1 > make[1]: Leaving directory `/path/to/dtn/DTN2/oasys' > make: *** [oasys] Error 2 > > The following snippet from BerkeleyDBStore.cc is the offender: > > /* > * BerkeleyDB depends on StorageConfig > */ > OASYS_DECLARE_INIT_MODULE_1(oasys, BerkeleyDBStore, "oasys::StorageConfig") { > BerkeleyDBStore::init(); > return 0; > } > > Thanks for your time, > jw > _______________________________________________ > dtn-bugs mailing list > dtn-bugs@mailman.dtnrg.org > http://mailman.dtnrg.org/mailman/listinfo/dtn-bugs Received: from deliverator6.gatech.edu (IDENT:postfix@deliverator6.gatech.edu [130.207.165.168]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j56HuXV27125 for ; Mon, 6 Jun 2005 10:56:33 -0700 Received: from hormel1.gatech.edu (hormel1.prism.gatech.edu [130.207.171.11]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "hormel1.prism.gatech.edu", Issuer "Tech Support CA" (verified OK)) by deliverator6.gatech.edu (Postfix) with ESMTP id 08B831F19 for ; Mon, 6 Jun 2005 13:56:33 -0400 (EDT) (envelope-from gtg472p@mail.gatech.edu) Received: from ([130.207.171.121]) by hormel1.gatech.edu with ESMTP with TLS id KP-BRAPX.16902920; Mon, 06 Jun 2005 13:56:11 -0400 Received: from deliverator1.gatech.edu (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 7B44C1FAB96; Mon, 6 Jun 2005 13:56:11 -0400 (EDT) (envelope-from gtg472p@mail.gatech.edu) Received: from webmail3.gatech.edu (webmail3.prism.gatech.edu [130.207.171.133]) by deliverator1.gatech.edu (Postfix) with ESMTP id 46B5D1FAB8C; Mon, 6 Jun 2005 13:56:11 -0400 (EDT) (envelope-from gtg472p@mail.gatech.edu) Received: from localhost (localhost [127.0.0.1]) by webmail3.gatech.edu (Postfix) with ESMTP id 35F02225A; Mon, 6 Jun 2005 13:56:11 -0400 (EDT) (envelope-from gtg472p@mail.gatech.edu) Received: from thingy.oit.umass.edu (thingy.oit.umass.edu [128.119.40.196]) by webmail.mail.gatech.edu (IMP) with HTTP for ; Mon, 6 Jun 2005 13:56:11 -0400 Message-ID: <1118080571.42a48e3b2bd7b@webmail.mail.gatech.edu> Date: Mon, 6 Jun 2005 13:56:11 -0400 From: Yang Chen To: dtn-users@mailman.dtnrg.org MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 User-Agent: Internet Messaging Program (IMP) 3.2.5 X-Originating-IP: 128.119.40.196 X-Authenticated-User: gtg472p Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by webbie.berkeley.intel-research.net id j56HuXV27125 Subject: [dtn-users] Compilation and Installation problem with the latest DTN2 CVS Sender: dtn-users-admin@mailman.dtnrg.org Errors-To: dtn-users-admin@mailman.dtnrg.org X-BeenThere: dtn-users@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-users@mailman.dtnrg.org List-Unsubscribe: , List-Id: discussion/answers list for users of the dtn reference implementation List-Post: List-Help: List-Subscribe: , List-Archive: hi, I am trying to run the DTN2 code on Mandrake 9.2 Linux (HaCom OpenBrick mini PC): gcc 3.3.1, tcl8.4.9, BerkeleyDB.4.3, tclreadline-2.1.0, I used the latest CVS and found the following problem during compiling: in these two files DTN2/daemon/dtnd.cc DTN2/sim/dtnsim.cc oasys::TclCommandInterp::init(argv[0]); caused the error since the TclCommandInterp::init() has been modified in the TclCommand.cc/h (DTN2/oasys/tclcmd) compared to the previous version (in DTN-2.1.1.tgz as TclCommandInterp::init(char* objv0, bool no_default_cmds = false) ) I changed the oasys::TclCommandInterp::init(argv[0]); to oasys::TclCommandInterp::init(); and the compilation finished successfully. When I tried "dtnd -t", I got the following messages: couldn't load file "/usr/lib/libtclreadline.so": libreadline.so.5: cannot open shared object file: NO such file or directory But this particular file is at /usr/lib/libtclreadline.so", which is a link to libtclreadline-2.1.0.so in the same directory. The following error occurs during "make install": error while loading shared libraries: libdb_cxx-4.3.so However, this file exists at /usr/local/BerkeleyDB.4.3/lib/ and this directory has been added to LD_LIBRARY_PATH. And I configured the BerkeleyDB with the -- enable-cxx option. So I turned back to DTN-2.1.1.tgz version following the same procedure: unzip sh configure -C make there is no compilation issue but the errors during install or dtnd -t are still there. Personally, I think there might be some issues with the tclreadline and BerkeleyDB installation. However, I followed the standard configure->make- >make install procedure as a root. No error occurs. Thx for attention and any information is appreciated. -Yang Received: from as2.cineca.com (as2.cineca.com [130.186.84.242]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j569A5V17552 for ; Mon, 6 Jun 2005 02:10:05 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by as2.cineca.com (Postfix) with ESMTP id 823F86595F for ; Mon, 6 Jun 2005 09:10:00 +0000 (UTC) Received: from unibo.mm.cineca.it (unibo.mm.cineca.it [130.186.10.202]) by as2.cineca.com (Postfix) with ESMTP id B398D65920 for ; Mon, 6 Jun 2005 09:09:58 +0000 (UTC) Received: from portcent.ing.unibo.it (portcent.ing.unibo.it [137.204.58.141]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) as user piero.cornice@studio.unibo.it by unibo.mm.cineca.it (Postfix) with ESMTP id E1A6549F7C for ; Mon, 6 Jun 2005 11:09:57 +0200 (MEST) From: piero To: dtn-users@mailman.dtnrg.org Content-Type: multipart/alternative; boundary="=-V5pIpV8HQ99ivc+E1KYp" Date: Mon, 06 Jun 2005 11:09:52 +0200 Message-Id: <1118048992.21697.3.camel@Ubertinux> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) X-Virus-Scanned: Cineca AppOs 0.85 at as2.cineca.com Subject: [dtn-users] compiling DTN Sender: dtn-users-admin@mailman.dtnrg.org Errors-To: dtn-users-admin@mailman.dtnrg.org X-BeenThere: dtn-users@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-users@mailman.dtnrg.org X-Reply-To: piero.cornice@studio.unibo.it List-Unsubscribe: , List-Id: discussion/answers list for users of the dtn reference implementation List-Post: List-Help: List-Subscribe: , List-Archive: --=-V5pIpV8HQ99ivc+E1KYp Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, i downloaded (by CVS) the latest DTN package and - while compiling it - i received this error: make[1]: Entering directory `/usr/local/DTN/DTN2/daemon' g++ -I.. -I../servlib -I/usr/local/include/ - I/usr/local/BerkeleyDB.4.3/include -g -fno-inline -MMD -MP -MT "dtnd.o dtnd.E dtnd.po" -Wall -Werror -c dtnd.cc -o dtnd.o dtnd.cc: In function `int main(int, char**)': dtnd.cc:191: error: no matching function for call to `oasys::TclCommandInterp:: init(char*&)' ../oasys/tclcmd/TclCommand.h:108: error: candidates are: static int oasys::TclCommandInterp::init() make[1]: *** [dtnd.o] Error 1 make[1]: Leaving directory `/usr/local/DTN/DTN2/daemon' make: *** [daemon] Error 2 ...can anybody help me please? Piero --=-V5pIpV8HQ99ivc+E1KYp Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, i downloaded (by CVS) the latest DTN package and - while compiling it - i received this error:

make[1]: Entering directory `/usr/local/DTN/DTN2/daemon'
g++ -I.. -I../servlib   -I/usr/local/include/ -I/usr/local/BerkeleyDB.4.3/include  -g -fno-inline  -MMD -MP -MT "dtnd.o dtnd.E dtnd.po" -Wall -Werror  -c dtnd.cc -o dtnd.o
dtnd.cc: In function `int main(int, char**)':
dtnd.cc:191: error: no matching function for call to `oasys::TclCommandInterp::
   init(char*&)'
../oasys/tclcmd/TclCommand.h:108: error: candidates are: static int
   oasys::TclCommandInterp::init()
make[1]: *** [dtnd.o] Error 1
make[1]: Leaving directory `/usr/local/DTN/DTN2/daemon'
make: *** [daemon] Error 2

...can anybody help me please?
Piero --=-V5pIpV8HQ99ivc+E1KYp-- Received: from pisco (pisco.CS.Berkeley.EDU [128.32.37.175]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j52KnJV04585 for ; Thu, 2 Jun 2005 13:49:19 -0700 Received: from demmer by pisco with local (Exim 4.50) id 1Ddwcx-0001m4-2j; Thu, 02 Jun 2005 13:49:19 -0700 Date: Thu, 2 Jun 2005 13:49:19 -0700 From: Michael Demmer To: Yun Cc: dtn-users@mailman.dtnrg.org Message-ID: <20050602204918.GD22270@pisco.cs.berkeley.edu> References: <20050602192645.GB22270@pisco.cs.berkeley.edu> <20050602195021.78230.qmail@web60123.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050602195021.78230.qmail@web60123.mail.yahoo.com> User-Agent: Mutt/1.4.2i Subject: [dtn-users] Re: [dtn-interest] DTN compile Sender: dtn-users-admin@mailman.dtnrg.org Errors-To: dtn-users-admin@mailman.dtnrg.org X-BeenThere: dtn-users@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-users@mailman.dtnrg.org List-Unsubscribe: , List-Id: discussion/answers list for users of the dtn reference implementation List-Post: List-Help: List-Subscribe: , List-Archive: Again, this looks like there's a bogus sunrpc installation: > ... > checking for library containing xdr_int... (cached) no -m Received: from web60123.mail.yahoo.com (web60123.mail.yahoo.com [209.73.178.91]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with SMTP id j52JoWV04200 for ; Thu, 2 Jun 2005 12:50:32 -0700 Received: (qmail 78232 invoked by uid 60001); 2 Jun 2005 19:50:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Ddm7nAte1RaaU/o3NjSH+yV1KyEWuQyDe0yDucCe5n9bADIxAWS1GNbXJHmyZaAEc89xx9iIOWZT71rpltv/yQoP6YqHnVvFpgaUw/2qvQxFTmiKffTYdk8IcqRfsZK1j4btwIcfhj61So6+ecq4S+7fL3qBsSsx/D9z3ZeQU+A= ; Message-ID: <20050602195021.78230.qmail@web60123.mail.yahoo.com> Received: from [130.85.93.28] by web60123.mail.yahoo.com via HTTP; Thu, 02 Jun 2005 12:50:21 PDT Date: Thu, 2 Jun 2005 12:50:21 -0700 (PDT) From: Yun To: Michael Demmer , dtn-users@mailman.dtnrg.org In-Reply-To: <20050602192645.GB22270@pisco.cs.berkeley.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1316453588-1117741821=:76637" Content-Transfer-Encoding: 8bit Subject: [dtn-users] Re: [dtn-interest] DTN compile Sender: dtn-users-admin@mailman.dtnrg.org Errors-To: dtn-users-admin@mailman.dtnrg.org X-BeenThere: dtn-users@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-users@mailman.dtnrg.org List-Unsubscribe: , List-Id: discussion/answers list for users of the dtn reference implementation List-Post: List-Help: List-Subscribe: , List-Archive: --0-1316453588-1117741821=:76637 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Thank you! I am running DTN-2.1.1 After installing sunrpc package, the previous problem is solved. But another problem comes :( Here is the output of configure: $ ./configure -C configure: loading cache config.cache checking compilation target... native checking whether to compile with debugging... yes checking whether to compile with memory debugging... no checking whether to compile with optimization... no checking whether to build and link statically... yes checking for a C compiler (trying gcc gcc-3.3 gcc-3.2 gcc-2.96 gcc296 gcc-2.95 g cc295)... checking for gcc... (cached) gcc checking for C compiler default output... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... (cached) o checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ANSI C... (cached) none needed checking for a C++ compiler (trying g++ g++-3.3 g++-3.2 g++-2.96 g++296 g++-2.95 g++295)... checking for g++... (cached) g++ checking whether we are using the GNU C++ compiler... (cached) yes checking whether g++ accepts -g... (cached) yes checking for gawk... (cached) gawk checking for a BSD-compatible install... (cached) /usr/bin/install -c checking whether make sets $(MAKE)... (cached) yes checking for ranlib... (cached) ranlib checking for the version of the gcc compiler... (cached) 3.3.3 checking whether gcc accepts -Wno-long-double (Apple OSX only)... (cached) no checking whether std::string::reserve() is broken... (cached) no checking for library containing pthread_create... (cached) none required checking for pthread_yield... (cached) no checking for library containing sched_yield... (cached) none required checking for library containing socket... (cached) none required checking for library containing gethostbyname... (cached) none required checking for library containing xdr_int... (cached) no checking for tcl installation... (cached) /usr/include/tcl.h, /usr/lib -ltcl checking for Berkeley DB installation... (cached) /usr/local/BerkeleyDB.4.3/incl ude/db_cxx.h, /usr/local/BerkeleyDB.4.3/lib -ldb_cxx-4.3 checking for dirent.h that defines DIR... (cached) yes checking for library containing opendir... (cached) none required checking how to run the C preprocessor... (cached) gcc -E checking for egrep... (cached) grep -E checking for ANSI C header files... (cached) yes checking for sys/types.h... (cached) yes checking for sys/stat.h... (cached) yes checking for stdlib.h... (cached) yes checking for string.h... (cached) yes checking for memory.h... (cached) yes checking for strings.h... (cached) yes checking for inttypes.h... (cached) yes checking for stdint.h... (cached) yes checking for unistd.h... (cached) yes checking for arpa/inet.h... (cached) yes checking for err.h... (cached) yes checking for fcntl.h... (cached) yes checking for float.h... (cached) yes checking for limits.h... (cached) yes checking for locale.h... (cached) yes checking for netdb.h... (cached) yes checking for netinet/in.h... (cached) yes checking for stddef.h... (cached) yes checking for stdint.h... (cached) yes checking for stdlib.h... (cached) yes checking for string.h... (cached) yes checking for synch.h... (cached) no checking for sys/cdefs.h... (cached) yes checking for sys/ioctl.h... (cached) yes checking for sys/socket.h... (cached) yes checking for sys/time.h... (cached) yes checking for termios.h... (cached) yes checking for unistd.h... (cached) yes checking for wchar.h... (cached) yes checking for stdbool.h that conforms to C99... (cached) yes checking for _Bool... (cached) yes checking for an ANSI C-conforming const... (cached) yes checking for inline... (cached) inline checking for mode_t... (cached) yes checking for off_t... (cached) yes checking for size_t... (cached) yes checking whether time.h and sys/time.h may both be included... (cached) yes checking for working volatile... (cached) yes checking for ptrdiff_t... (cached) yes checking for uint32_t... (cached) yes checking for u_int32_t... (cached) yes checking for stdlib.h... (cached) yes checking for GNU libc compatible malloc... (cached) yes checking for stdlib.h... (cached) yes checking for GNU libc compatible realloc... (cached) yes checking for working memcmp... (cached) yes checking for sys/select.h... (cached) yes checking for sys/socket.h... (cached) yes checking types of arguments for select... (cached) int,fd_set *,struct timeval * checking return type of signal handlers... (cached) void checking whether lstat dereferences a symlink specified with a trailing slash... (cached) yes checking whether stat accepts an empty string... (cached) no checking for working strtod... (cached) yes checking for vprintf... (cached) yes checking for _doprnt... (cached) no checking whether math.h defines fpclassify... (cached) yes checking for bzero... (cached) yes checking for ftruncate... (cached) yes checking for getaddrinfo... (cached) no checking for gethostbyname... (cached) yes checking for gethostbyname_r... (cached) no checking for getopt_long... (cached) yes checking for gettimeofday... (cached) yes checking for inet_aton... (cached) yes checking for inet_pton... (cached) no checking for isascii... (cached) yes checking for localeconv... (cached) yes checking for memchr... (cached) yes checking for memmove... (cached) yes checking for memset... (cached) yes checking for pthread_yield... (cached) no checking for sched_yield... (cached) yes checking for mkdir... (cached) yes checking for select... (cached) yes checking for setenv... (cached) yes checking for socket... (cached) yes checking for strcasecmp... (cached) yes checking for strncasecmp... (cached) yes checking for strchr... (cached) yes checking for strcspn... (cached) yes checking for strdup... (cached) yes checking for strerror... (cached) yes checking for strrchr... (cached) yes checking for strspn... (cached) yes checking for strstr... (cached) yes checking for strtol... (cached) yes checking for strtoul... (cached) yes configure: creating ./config.status config.status: creating Rules.make config.status: creating config.h config.status: creating auto.config.h config.status: auto.config.h is unchanged configure: configuring in oasys configure: running /bin/bash './configure' --prefix=/usr/local '-C' --cache-fil e=../config.cache --srcdir=. configure: loading cache ../config.cache checking compilation target... native checking whether to compile with debugging... yes checking whether to compile with memory debugging... no checking whether to compile with optimization... no checking whether to build and link statically... yes checking for a C compiler (trying gcc gcc-3.3 gcc-3.2 gcc-2.96 gcc296 gcc-2.95 g cc295)... checking for gcc... (cached) gcc checking for C compiler default output... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... (cached) o checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ANSI C... (cached) none needed checking for a C++ compiler (trying g++ g++-3.3 g++-3.2 g++-2.96 g++296 g++-2.95 g++295)... checking for g++... (cached) g++ checking whether we are using the GNU C++ compiler... (cached) yes checking whether g++ accepts -g... (cached) yes checking for gawk... (cached) gawk checking for a BSD-compatible install... (cached) /usr/bin/install -c checking whether make sets $(MAKE)... (cached) yes checking for ranlib... (cached) ranlib checking for the version of the gcc compiler... (cached) 3.3.3 checking whether gcc accepts -Wno-long-double (Apple OSX only)... (cached) no checking whether std::string::reserve() is broken... (cached) no checking whether a conflicting debug/debug.h exists (Apple OSX only)... no check needed checking for library containing pthread_create... (cached) none required checking for pthread_yield... (cached) no checking for library containing sched_yield... (cached) none required checking for library containing socket... (cached) none required checking for library containing gethostbyname... (cached) none required checking for library containing xdr_int... (cached) no checking for tcl installation... (cached) /usr/include/tcl.h, /usr/lib -ltcl checking for Berkeley DB installation... (cached) /usr/local/BerkeleyDB.4.3/incl ude/db_cxx.h, /usr/local/BerkeleyDB.4.3/lib -ldb_cxx-4.3 checking for dirent.h that defines DIR... (cached) yes checking for library containing opendir... (cached) none required checking how to run the C preprocessor... (cached) gcc -E checking for egrep... (cached) grep -E checking for ANSI C header files... (cached) yes checking for sys/types.h... (cached) yes checking for sys/stat.h... (cached) yes checking for stdlib.h... (cached) yes checking for string.h... (cached) yes checking for memory.h... (cached) yes checking for strings.h... (cached) yes checking for inttypes.h... (cached) yes checking for stdint.h... (cached) yes checking for unistd.h... (cached) yes checking for arpa/inet.h... (cached) yes checking for err.h... (cached) yes checking for fcntl.h... (cached) yes checking for float.h... (cached) yes checking for limits.h... (cached) yes checking for locale.h... (cached) yes checking for netdb.h... (cached) yes checking for netinet/in.h... (cached) yes checking for stddef.h... (cached) yes checking for stdint.h... (cached) yes checking for stdlib.h... (cached) yes checking for string.h... (cached) yes checking for synch.h... (cached) no checking for sys/cdefs.h... (cached) yes checking for sys/ioctl.h... (cached) yes checking for sys/socket.h... (cached) yes checking for sys/time.h... (cached) yes checking for unistd.h... (cached) yes checking for wchar.h... (cached) yes checking for stdbool.h that conforms to C99... (cached) yes checking for _Bool... (cached) yes checking for an ANSI C-conforming const... (cached) yes checking for inline... (cached) inline checking for mode_t... (cached) yes checking for off_t... (cached) yes checking for size_t... (cached) yes checking whether time.h and sys/time.h may both be included... (cached) yes checking for working volatile... (cached) yes checking for ptrdiff_t... (cached) yes checking for uint32_t... (cached) yes checking for u_int32_t... (cached) yes checking for stdlib.h... (cached) yes checking for GNU libc compatible malloc... (cached) yes checking for stdlib.h... (cached) yes checking for GNU libc compatible realloc... (cached) yes checking for working memcmp... (cached) yes checking return type of signal handlers... (cached) void checking whether lstat dereferences a symlink specified with a trailing slash... (cached) yes checking whether stat accepts an empty string... (cached) no checking for working strtod... (cached) yes checking for vprintf... (cached) yes checking for _doprnt... (cached) no checking whether math.h defines fpclassify... (cached) yes checking for bzero... (cached) yes checking for ftruncate... (cached) yes checking for getaddrinfo... (cached) no checking for gethostbyname... (cached) yes checking for gethostbyname_r... (cached) no checking for getopt_long... (cached) yes checking for gettimeofday... (cached) yes checking for inet_aton... (cached) yes checking for inet_pton... (cached) no checking for isascii... (cached) yes checking for localeconv... (cached) yes checking for memchr... (cached) yes checking for memmove... (cached) yes checking for memset... (cached) yes checking for pthread_yield... (cached) no checking for sched_yield... (cached) yes checking for mkdir... (cached) yes checking for setenv... (cached) yes checking for socket... (cached) yes checking for strcasecmp... (cached) yes checking for strncasecmp... (cached) yes checking for strchr... (cached) yes checking for strcspn... (cached) yes checking for strdup... (cached) yes checking for strerror... (cached) yes checking for strrchr... (cached) yes checking for strspn... (cached) yes checking for strstr... (cached) yes checking for strtol... (cached) yes checking for strtoul... (cached) yes configure: creating ./config.status config.status: creating Rules.make config.status: creating config.h config.status: config.h is unchanged DTN2 configure state: Target/Tools: TARGET is: native CC is: gcc (version 3.3.3) CXX is: g++ Options: Debug: -g -fno-inline Optimize: Static: yes External packages: tcl: /usr/include/tcl.h -L/usr/lib -ltcl db: /usr/local/BerkeleyDB.4.3/include/db.h -L/usr/local/BerkeleyDB.4.3/lib -ld b_cxx-4.3 When I compile it this time, it shows the following at last: make[1]: Entering directory `/home/user/DTN2/daemon' g++ -I.. -I../servlib -I/usr/local/BerkeleyDB.4.3/include -g -fno-inline -MM D -MP -MT "dtnd.o dtnd.E dtnd.po" -Wall -Werror -c dtnd.cc -o dtnd.o g++ dtnd.o ../version.c ../applib/libdtnapisrv.a ../servlib/libdtnserv.a ../oasy s/liboasys.a -o dtnd -L/usr/local/BerkeleyDB.4.3/lib -ltcl -ldb_cxx-4.3 ../applib/libdtnapisrv.a(APIServer.o): In function `_ZN3dtn9APIServerC2Ev': /home/user/DTN2/applib/APIServer.cc:127: undefined reference to `_xdrmem_create' /home/user/DTN2/applib/APIServer.cc:128: undefined reference to `_xdrmem_create' ../applib/libdtnapisrv.a(APIServer.o): In function `_ZN3dtn9APIServerC1Ev': /home/user/DTN2/applib/APIServer.cc:127: undefined reference to `_xdrmem_create' /home/user/DTN2/applib/APIServer.cc:128: undefined reference to `_xdrmem_create' ../applib/libdtnapisrv.a(dtn_types_xdr.o): In function `xdr_DTN_STATUS': /home/user/DTN2/applib/dtn_types_xdr.c:87: undefined reference to `_xdr_int' ../applib/libdtnapisrv.a(dtn_types_xdr.o): In function `xdr_dtn_tuple_t': /home/user/DTN2/applib/dtn_types_xdr.c:114: undefined reference to `_xdr_char' /home/user/DTN2/applib/dtn_types_xdr.c:114: undefined reference to `_xdr_vector' /home/user/DTN2/applib/dtn_types_xdr.c:117: undefined reference to `_xdr_bytes' ../applib/libdtnapisrv.a(dtn_types_xdr.o): In function `xdr_dtn_info_request_t': /home/user/DTN2/applib/dtn_types_xdr.c:134: undefined reference to `_xdr_enum' ../applib/libdtnapisrv.a(dtn_types_xdr.o): In function `xdr_dtn_inforeq_interfac es_t': /home/user/DTN2/applib/dtn_types_xdr.c:147: undefined reference to `_xdr_vector' ../applib/libdtnapisrv.a(dtn_types_xdr.o): In function `xdr_dtn_reg_id_t': /home/user/DTN2/applib/dtn_types_xdr.c:185: undefined reference to `_xdr_u_int' ../applib/libdtnapisrv.a(dtn_types_xdr.o): In function `xdr_dtn_timeval_t': /home/user/DTN2/applib/dtn_types_xdr.c:199: undefined reference to `_xdr_u_int' ../applib/libdtnapisrv.a(dtn_types_xdr.o): In function `xdr_dtn_reg_action_t': /home/user/DTN2/applib/dtn_types_xdr.c:222: undefined reference to `_xdr_enum' ../applib/libdtnapisrv.a(dtn_types_xdr.o): In function `xdr_dtn_reg_info_t': /home/user/DTN2/applib/dtn_types_xdr.c:244: undefined reference to `_xdr_bytes' ../applib/libdtnapisrv.a(dtn_types_xdr.o): In function `xdr_dtn_bundle_priority_ t': /home/user/DTN2/applib/dtn_types_xdr.c:262: undefined reference to `_xdr_enum' ../applib/libdtnapisrv.a(dtn_types_xdr.o): In function `xdr_dtn_bundle_delivery_ opts_t': /home/user/DTN2/applib/dtn_types_xdr.c:285: undefined reference to `_xdr_enum' ../applib/libdtnapisrv.a(dtn_types_xdr.o): In function `xdr_dtn_bundle_spec_t': /home/user/DTN2/applib/dtn_types_xdr.c:307: undefined reference to `_xdr_int' /home/user/DTN2/applib/dtn_types_xdr.c:309: undefined reference to `_xdr_int' ../applib/libdtnapisrv.a(dtn_types_xdr.o): In function `xdr_dtn_bundle_payload_l ocation_t': /home/user/DTN2/applib/dtn_types_xdr.c:328: undefined reference to `_xdr_enum' ../applib/libdtnapisrv.a(dtn_types_xdr.o): In function `xdr_dtn_bundle_payload_t ': /home/user/DTN2/applib/dtn_types_xdr.c:342: undefined reference to `_xdr_bytes' /home/user/DTN2/applib/dtn_types_xdr.c:346: undefined reference to `_xdr_bytes' ../applib/libdtnapisrv.a(dtn_types_xdr.o): In function `xdr_dtn_bundle_auth_t': /home/user/DTN2/applib/dtn_types_xdr.c:364: undefined reference to `_xdr_bytes' collect2: ld returned 1 exit status make[1]: *** [dtnd] Error 1 make[1]: Leaving directory `/home/user/DTN2/daemon' make: *** [daemon] Error 2 I couldn't find the definition of "xdrmem_create" function. Any ideas? Yun Michael Demmer wrote: (reposted from dtn-interest) It looks like it's not correctly finding the rpc installation. Can you verify that you have the sunrpc package installed and up to date in cygwin. This is a little strange since the configure script should check for that. Which version of the source code are you using? Also, can you post the full output of running configure on your system. -m > Hi all, > > I am trying to install DTN package on Windows machine with cygwin. I did the configure successfully, but when I compile it, it shows: > gcc -I.. -I../servlib -I/usr/local/BerkeleyDB.4.3/include -g -fno-inline -c > dtn_types_xdr.c -o dtn_types_xdr.o > In file included from dtn_types_xdr.c:6: > dtn_types.h:9:21: rpc/rpc.h: No such file or directory > dtn_types.h:67:21: rpc/rpc.h: No such file or directory > In file included from dtn_types_xdr.c:6: > dtn_types.h:112: error: parse error before "u_int" > dtn_types.h:112: warning: no semicolon at end of struct or union > dtn_types.h:112: warning: no semicolon at end of struct or union > .... > and a lot of errors similarly. > Could anyone help me about this situation? > Thank you! > > Yun > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com --------------------------------- Discover Yahoo! Get on-the-go sports scores, stock quotes, news & more. Check it out! --0-1316453588-1117741821=:76637 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Thank you!
I am running DTN-2.1.1
After installing sunrpc package, the previous problem is solved. But another problem comes :(
Here is the output of configure:
$ ./configure -C
configure: loading cache config.cache
checking compilation target... native
checking whether to compile with debugging... yes
checking whether to compile with memory debugging... no
checking whether to compile with optimization... no
checking whether to build and link statically... yes
checking for a C compiler (trying gcc gcc-3.3 gcc-3.2 gcc-2.96 gcc296 gcc-2.95 g
cc295)...
checking for gcc... (cached) gcc
checking for C compiler default output... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... .exe
checking for suffix of object files... (cached) o
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ANSI C... (cached) none needed
checking for a C++ compiler (trying g++ g++-3.3 g++-3.2 g++-2.96 g++296 g++-2.95
 g++295)...
checking for g++... (cached) g++
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ accepts -g... (cached) yes
checking for gawk... (cached) gawk
checking for a BSD-compatible install... (cached) /usr/bin/install -c
checking whether make sets $(MAKE)... (cached) yes
checking for ranlib... (cached) ranlib
checking for the version of the gcc compiler... (cached) 3.3.3
checking whether gcc accepts -Wno-long-double (Apple OSX only)... (cached) no
checking whether std::string::reserve() is broken... (cached) no
checking for library containing pthread_create... (cached) none required
checking for pthread_yield... (cached) no
checking for library containing sched_yield... (cached) none required
checking for library containing socket... (cached) none required
checking for library containing gethostbyname... (cached) none required
checking for library containing xdr_int... (cached) no
checking for tcl installation... (cached) /usr/include/tcl.h, /usr/lib -ltcl
checking for Berkeley DB installation... (cached) /usr/local/BerkeleyDB.4.3/incl
ude/db_cxx.h, /usr/local/BerkeleyDB.4.3/lib -ldb_cxx-4.3
checking for dirent.h that defines DIR... (cached) yes
checking for library containing opendir... (cached) none required
checking how to run the C preprocessor... (cached) gcc -E
checking for egrep... (cached) grep -E
checking for ANSI C header files... (cached) yes
checking for sys/types.h... (cached) yes
checking for sys/stat.h... (cached) yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for memory.h... (cached) yes
checking for strings.h... (cached) yes
checking for inttypes.h... (cached) yes
checking for stdint.h... (cached) yes
checking for unistd.h... (cached) yes
checking for arpa/inet.h... (cached) yes
checking for err.h... (cached) yes
checking for fcntl.h... (cached) yes
checking for float.h... (cached) yes
checking for limits.h... (cached) yes
checking for locale.h... (cached) yes
checking for netdb.h... (cached) yes
checking for netinet/in.h... (cached) yes
checking for stddef.h... (cached) yes
checking for stdint.h... (cached) yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for synch.h... (cached) no
checking for sys/cdefs.h... (cached) yes
checking for sys/ioctl.h... (cached) yes
checking for sys/socket.h... (cached) yes
checking for sys/time.h... (cached) yes
checking for termios.h... (cached) yes
checking for unistd.h... (cached) yes
checking for wchar.h... (cached) yes
checking for stdbool.h that conforms to C99... (cached) yes
checking for _Bool... (cached) yes
checking for an ANSI C-conforming const... (cached) yes
checking for inline... (cached) inline
checking for mode_t... (cached) yes
checking for off_t... (cached) yes
checking for size_t... (cached) yes
checking whether time.h and sys/time.h may both be included... (cached) yes
checking for working volatile... (cached) yes
checking for ptrdiff_t... (cached) yes
checking for uint32_t... (cached) yes
checking for u_int32_t... (cached) yes
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... (cached) yes
checking for stdlib.h... (cached) yes
checking for GNU libc compatible realloc... (cached) yes
checking for working memcmp... (cached) yes
checking for sys/select.h... (cached) yes
checking for sys/socket.h... (cached) yes
checking types of arguments for select... (cached) int,fd_set *,struct timeval *
checking return type of signal handlers... (cached) void
checking whether lstat dereferences a symlink specified with a trailing slash...
 (cached) yes
checking whether stat accepts an empty string... (cached) no
checking for working strtod... (cached) yes
checking for vprintf... (cached) yes
checking for _doprnt... (cached) no
checking whether math.h defines fpclassify... (cached) yes
checking for bzero... (cached) yes
checking for ftruncate... (cached) yes
checking for getaddrinfo... (cached) no
checking for gethostbyname... (cached) yes
checking for gethostbyname_r... (cached) no
checking for getopt_long... (cached) yes
checking for gettimeofday... (cached) yes
checking for inet_aton... (cached) yes
checking for inet_pton... (cached) no
checking for isascii... (cached) yes
checking for localeconv... (cached) yes
checking for memchr... (cached) yes
checking for memmove... (cached) yes
checking for memset... (cached) yes
checking for pthread_yield... (cached) no
checking for sched_yield... (cached) yes
checking for mkdir... (cached) yes
checking for select... (cached) yes
checking for setenv... (cached) yes
checking for socket... (cached) yes
checking for strcasecmp... (cached) yes
checking for strncasecmp... (cached) yes
checking for strchr... (cached) yes
checking for strcspn... (cached) yes
checking for strdup... (cached) yes
checking for strerror... (cached) yes
checking for strrchr... (cached) yes
checking for strspn... (cached) yes
checking for strstr... (cached) yes
checking for strtol... (cached) yes
checking for strtoul... (cached) yes
configure: creating ./config.status
config.status: creating Rules.make
config.status: creating config.h
config.status: creating auto.config.h
config.status: auto.config.h is unchanged
configure: configuring in oasys
configure: running /bin/bash './configure' --prefix=/usr/local  '-C' --cache-fil
e=../config.cache --srcdir=.
configure: loading cache ../config.cache
checking compilation target... native
checking whether to compile with debugging... yes
checking whether to compile with memory debugging... no
checking whether to compile with optimization... no
checking whether to build and link statically... yes
checking for a C compiler (trying gcc gcc-3.3 gcc-3.2 gcc-2.96 gcc296 gcc-2.95 g
cc295)...
checking for gcc... (cached) gcc
checking for C compiler default output... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... .exe
checking for suffix of object files... (cached) o
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ANSI C... (cached) none needed
checking for a C++ compiler (trying g++ g++-3.3 g++-3.2 g++-2.96 g++296 g++-2.95
 g++295)...
checking for g++... (cached) g++
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ accepts -g... (cached) yes
checking for gawk... (cached) gawk
checking for a BSD-compatible install... (cached) /usr/bin/install -c
checking whether make sets $(MAKE)... (cached) yes
checking for ranlib... (cached) ranlib
checking for the version of the gcc compiler... (cached) 3.3.3
checking whether gcc accepts -Wno-long-double (Apple OSX only)... (cached) no
checking whether std::string::reserve() is broken... (cached) no
checking whether a conflicting debug/debug.h exists (Apple OSX only)... no check
 needed
checking for library containing pthread_create... (cached) none required
checking for pthread_yield... (cached) no
checking for library containing sched_yield... (cached) none required
checking for library containing socket... (cached) none required
checking for library containing gethostbyname... (cached) none required
checking for library containing xdr_int... (cached) no
checking for tcl installation... (cached) /usr/include/tcl.h, /usr/lib -ltcl
checking for Berkeley DB installation... (cached) /usr/local/BerkeleyDB.4.3/incl
ude/db_cxx.h, /usr/local/BerkeleyDB.4.3/lib -ldb_cxx-4.3
checking for dirent.h that defines DIR... (cached) yes
checking for library containing opendir... (cached) none required
checking how to run the C preprocessor... (cached) gcc -E
checking for egrep... (cached) grep -E
checking for ANSI C header files... (cached) yes
checking for sys/types.h... (cached) yes
checking for sys/stat.h... (cached) yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for memory.h... (cached) yes
checking for strings.h... (cached) yes
checking for inttypes.h... (cached) yes
checking for stdint.h... (cached) yes
checking for unistd.h... (cached) yes
checking for arpa/inet.h... (cached) yes
checking for err.h... (cached) yes
checking for fcntl.h... (cached) yes
checking for float.h... (cached) yes
checking for limits.h... (cached) yes
checking for locale.h... (cached) yes
checking for netdb.h... (cached) yes
checking for netinet/in.h... (cached) yes
checking for stddef.h... (cached) yes
checking for stdint.h... (cached) yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for synch.h... (cached) no
checking for sys/cdefs.h... (cached) yes
checking for sys/ioctl.h... (cached) yes
checking for sys/socket.h... (cached) yes
checking for sys/time.h... (cached) yes
checking for unistd.h... (cached) yes
checking for wchar.h... (cached) yes
checking for stdbool.h that conforms to C99... (cached) yes
checking for _Bool... (cached) yes
checking for an ANSI C-conforming const... (cached) yes
checking for inline... (cached) inline
checking for mode_t... (cached) yes
checking for off_t... (cached) yes
checking for size_t... (cached) yes
checking whether time.h and sys/time.h may both be included... (cached) yes
checking for working volatile... (cached) yes
checking for ptrdiff_t... (cached) yes
checking for uint32_t... (cached) yes
checking for u_int32_t... (cached) yes
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... (cached) yes
checking for stdlib.h... (cached) yes
checking for GNU libc compatible realloc... (cached) yes
checking for working memcmp... (cached) yes
checking return type of signal handlers... (cached) void
checking whether lstat dereferences a symlink specified with a trailing slash...
 (cached) yes
checking whether stat accepts an empty string... (cached) no
checking for working strtod... (cached) yes
checking for vprintf... (cached) yes
checking for _doprnt... (cached) no
checking whether math.h defines fpclassify... (cached) yes
checking for bzero... (cached) yes
checking for ftruncate... (cached) yes
checking for getaddrinfo... (cached) no
checking for gethostbyname... (cached) yes
checking for gethostbyname_r... (cached) no
checking for getopt_long... (cached) yes
checking for gettimeofday... (cached) yes
checking for inet_aton... (cached) yes
checking for inet_pton... (cached) no
checking for isascii... (cached) yes
checking for localeconv... (cached) yes
checking for memchr... (cached) yes
checking for memmove... (cached) yes
checking for memset... (cached) yes
checking for pthread_yield... (cached) no
checking for sched_yield... (cached) yes
checking for mkdir... (cached) yes
checking for setenv... (cached) yes
checking for socket... (cached) yes
checking for strcasecmp... (cached) yes
checking for strncasecmp... (cached) yes
checking for strchr... (cached) yes
checking for strcspn... (cached) yes
checking for strdup... (cached) yes
checking for strerror... (cached) yes
checking for strrchr... (cached) yes
checking for strspn... (cached) yes
checking for strstr... (cached) yes
checking for strtol... (cached) yes
checking for strtoul... (cached) yes
configure: creating ./config.status
config.status: creating Rules.make
config.status: creating config.h
config.status: config.h is unchanged
DTN2 configure state:
Target/Tools:
  TARGET is: native
  CC is: gcc (version 3.3.3)
  CXX is: g++
Options:
  Debug: -g -fno-inline
  Optimize:
  Static: yes
External packages:
  tcl: /usr/include/tcl.h -L/usr/lib -ltcl
  db: /usr/local/BerkeleyDB.4.3/include/db.h -L/usr/local/BerkeleyDB.4.3/lib -ld
b_cxx-4.3
 
When I compile it this time, it shows the following at last:
make[1]: Entering directory `/home/user/DTN2/daemon'
g++ -I.. -I../servlib   -I/usr/local/BerkeleyDB.4.3/include  -g -fno-inline  -MM
D -MP -MT "dtnd.o dtnd.E dtnd.po" -Wall -Werror  -c dtnd.cc -o dtnd.o
g++ dtnd.o ../version.c ../applib/libdtnapisrv.a ../servlib/libdtnserv.a ../oasy
s/liboasys.a  -o dtnd -L/usr/local/BerkeleyDB.4.3/lib  -ltcl -ldb_cxx-4.3
../applib/libdtnapisrv.a(APIServer.o): In function `_ZN3dtn9APIServerC2Ev':
/home/user/DTN2/applib/APIServer.cc:127: undefined reference to `_xdrmem_create'
/home/user/DTN2/applib/APIServer.cc:128: undefined reference to `_xdrmem_create'
../applib/libdtnapisrv.a(APIServer.o): In function `_ZN3dtn9APIServerC1Ev':
/home/user/DTN2/applib/APIServer.cc:127: undefined reference to `_xdrmem_create'
/home/user/DTN2/applib/APIServer.cc:128: undefined reference to `_xdrmem_create'
../applib/libdtnapisrv.a(dtn_types_xdr.o): In function `xdr_DTN_STATUS':
/home/user/DTN2/applib/dtn_types_xdr.c:87: undefined reference to `_xdr_int'
../applib/libdtnapisrv.a(dtn_types_xdr.o): In function `xdr_dtn_tuple_t':
/home/user/DTN2/applib/dtn_types_xdr.c:114: undefined reference to `_xdr_char'
/home/user/DTN2/applib/dtn_types_xdr.c:114: undefined reference to `_xdr_vector'
/home/user/DTN2/applib/dtn_types_xdr.c:117: undefined reference to `_xdr_bytes'
../applib/libdtnapisrv.a(dtn_types_xdr.o): In function `xdr_dtn_info_request_t':
/home/user/DTN2/applib/dtn_types_xdr.c:134: undefined reference to `_xdr_enum'
../applib/libdtnapisrv.a(dtn_types_xdr.o): In function `xdr_dtn_inforeq_interfac
es_t':
/home/user/DTN2/applib/dtn_types_xdr.c:147: undefined reference to `_xdr_vector'
../applib/libdtnapisrv.a(dtn_types_xdr.o): In function `xdr_dtn_reg_id_t':
/home/user/DTN2/applib/dtn_types_xdr.c:185: undefined reference to `_xdr_u_int'
../applib/libdtnapisrv.a(dtn_types_xdr.o): In function `xdr_dtn_timeval_t':
/home/user/DTN2/applib/dtn_types_xdr.c:199: undefined reference to `_xdr_u_int'
../applib/libdtnapisrv.a(dtn_types_xdr.o): In function `xdr_dtn_reg_action_t':
/home/user/DTN2/applib/dtn_types_xdr.c:222: undefined reference to `_xdr_enum'
../applib/libdtnapisrv.a(dtn_types_xdr.o): In function `xdr_dtn_reg_info_t':
/home/user/DTN2/applib/dtn_types_xdr.c:244: undefined reference to `_xdr_bytes'
../applib/libdtnapisrv.a(dtn_types_xdr.o): In function `xdr_dtn_bundle_priority_
t':
/home/user/DTN2/applib/dtn_types_xdr.c:262: undefined reference to `_xdr_enum'
../applib/libdtnapisrv.a(dtn_types_xdr.o): In function `xdr_dtn_bundle_delivery_
opts_t':
/home/user/DTN2/applib/dtn_types_xdr.c:285: undefined reference to `_xdr_enum'
../applib/libdtnapisrv.a(dtn_types_xdr.o): In function `xdr_dtn_bundle_spec_t':
/home/user/DTN2/applib/dtn_types_xdr.c:307: undefined reference to `_xdr_int'
/home/user/DTN2/applib/dtn_types_xdr.c:309: undefined reference to `_xdr_int'
../applib/libdtnapisrv.a(dtn_types_xdr.o): In function `xdr_dtn_bundle_payload_l
ocation_t':
/home/user/DTN2/applib/dtn_types_xdr.c:328: undefined reference to `_xdr_enum'
../applib/libdtnapisrv.a(dtn_types_xdr.o): In function `xdr_dtn_bundle_payload_t
':
/home/user/DTN2/applib/dtn_types_xdr.c:342: undefined reference to `_xdr_bytes'
/home/user/DTN2/applib/dtn_types_xdr.c:346: undefined reference to `_xdr_bytes'
../applib/libdtnapisrv.a(dtn_types_xdr.o): In function `xdr_dtn_bundle_auth_t':
/home/user/DTN2/applib/dtn_types_xdr.c:364: undefined reference to `_xdr_bytes'
collect2: ld returned 1 exit status
make[1]: *** [dtnd] Error 1
make[1]: Leaving directory `/home/user/DTN2/daemon'
make: *** [daemon] Error 2
 
I couldn't find the definition of "xdrmem_create" function. Any ideas?
 
Yun

Michael Demmer <demmer@cs.berkeley.edu> wrote:

(reposted from dtn-interest)

It looks like it's not correctly finding the rpc installation. Can you
verify that you have the sunrpc package installed and up to date in
cygwin.

This is a little strange since the configure script should check for
that. Which version of the source code are you using? Also, can you
post the full output of running configure on your system.

-m


> Hi all,
>
> I am trying to install DTN package on Windows machine with cygwin. I did the configure successfully, but when I compile it, it shows:
> gcc -I.. -I../servlib -I/usr/local/BerkeleyDB.4.3/include -g -fno-inline -c
> dtn_types_xdr.c -o dtn_types_xdr.o
> In file included from dtn_types_xdr.c:6:
> dtn_types.h:9:21: rpc/rpc.h: No such file or directory
> dtn_types.h:67:21: rpc/rpc.h: No such file or directory
> In file included from dtn_types_xdr.c:6:
> dtn_types.h:112: error: parse error before "u_int"
> dtn_types.h:112: warning: no semicolon at end of struct or union
> dtn_types.h:112: warning: no semicolon at end of struct or union
> ....
> and a lot of errors similarly.
> Could anyone help me about this situation?
> Thank you!
>
> Yun
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com

Discover Yahoo!
Get on-the-go sports scores, stock quotes, news & more. Check it out! --0-1316453588-1117741821=:76637-- Received: from pisco (pisco.CS.Berkeley.EDU [128.32.37.175]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j52JQjV03968 for ; Thu, 2 Jun 2005 12:26:45 -0700 Received: from demmer by pisco with local (Exim 4.50) id 1DdvL3-0001W0-N2; Thu, 02 Jun 2005 12:26:45 -0700 Date: Thu, 2 Jun 2005 12:26:45 -0700 From: Michael Demmer To: Yun Cc: dtn-users@mailman.dtnrg.org Message-ID: <20050602192645.GB22270@pisco.cs.berkeley.edu> References: <20050602190220.39000.qmail@web60114.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050602190220.39000.qmail@web60114.mail.yahoo.com> User-Agent: Mutt/1.4.2i Subject: [dtn-users] Re: [dtn-interest] DTN compile Sender: dtn-users-admin@mailman.dtnrg.org Errors-To: dtn-users-admin@mailman.dtnrg.org X-BeenThere: dtn-users@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-users@mailman.dtnrg.org List-Unsubscribe: , List-Id: discussion/answers list for users of the dtn reference implementation List-Post: List-Help: List-Subscribe: , List-Archive: (reposted from dtn-interest) It looks like it's not correctly finding the rpc installation. Can you verify that you have the sunrpc package installed and up to date in cygwin. This is a little strange since the configure script should check for that. Which version of the source code are you using? Also, can you post the full output of running configure on your system. -m > Hi all, > > I am trying to install DTN package on Windows machine with cygwin. I did the configure successfully, but when I compile it, it shows: > gcc -I.. -I../servlib -I/usr/local/BerkeleyDB.4.3/include -g -fno-inline -c > dtn_types_xdr.c -o dtn_types_xdr.o > In file included from dtn_types_xdr.c:6: > dtn_types.h:9:21: rpc/rpc.h: No such file or directory > dtn_types.h:67:21: rpc/rpc.h: No such file or directory > In file included from dtn_types_xdr.c:6: > dtn_types.h:112: error: parse error before "u_int" > dtn_types.h:112: warning: no semicolon at end of struct or union > dtn_types.h:112: warning: no semicolon at end of struct or union > .... > and a lot of errors similarly. > Could anyone help me about this situation? > Thank you! > > Yun > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com