My research is about minimizing End to End retransmission delay by touching Transport Layer Process to Process communication.
I did some changes to tcp.cc , changed window size. the changes i am doing are not affecting. ex: even if i removed tcp.cc file from NS2 folder but TCP topologies are still working, why is that?
Thanks!
Once you made any changes in .cc files then you have to run make command in your NS2.xx folder.
Related
I'm having an issue with some embedded mobile devices that have a buggy TCP stack. We're trying to update these devices but the firmware download fails, unless the mobile connection is very very good. Since it's an EDGE connection, it's usually bad.
Part of the problem is that the devices need quite a bit of time to write the data to storage. This is probably what leads to packet loss, but the connection never recovers.
I'm thinking that if I could control the connection at TCP level, I might be able to get around this problem. We tried changing the congestion control and it doesn't help, but we're still looking into that.
In the meantime I'd like to look into this option. Is there any way to do it, without writing my own TCP stack / kernel module?
I didn't find any way to do this so in the end I set up a new server and recompiled the linux kernel with a modified TCP_RTO_MAX value (5s instead of 120s). This seems to have solved my problem. My guess is that the network was not the actual issue but rather devices taking too long to store the data. This is a very specific case and this solution wouldn't help in any situation where the network connection is actually slow.
Hi Guys,
I'm working with a friend on network protocol simulation with ns-2,I'm new to this environment and facing some difficulties.
The one tutorial I used did this for the Westwood protocol, so I'll include my errors for that one just because it's a little simpler.
This is the guide I followed:
http://web.cs.ucla.edu/~nrl/hpi/tcpw/tcpw_ns2/tcp-westwood-ns2.html
Outline of steps:
Add tcp-westwood.cc & tcp-westwood.h files to tcp folder in
the main ns2 directory (ns-2.35)
Edit the makefile to include tcp-westwood.o file (within the obj_cc variable).
Add the appropriate lines to ns-default.tcl file (see link)
Recompile (recompile steps: go to ns-2.35 directory; type "./configure"; type
"make")
Goal:
To try out TCP Westwood protocol (a third party protocol source code) in ns-2 to simulate some network scenarios.
Problem:
When I run test.tcl using the Reno tcp protocol I get no errors. But when I change the line "set tcp [new Agent/TCP/Reno" to "set tcp [new Agent/TCP/Westwood" in the test.tcl file, I get the output from the screen shot (see attached).
I have upload code files here on google drive.
Any help or tip will be greatly appreciated.
I have a huge file on a server, e.g. a movie. Someone starts to down load that file. The download is not immediate, because the network has a certain maximum transmission rate. While the server is in the process of sending the file, I enter the command to delete the file.
What is the expected behavior?
Is the transmission cancelled?
Is the transmission completed first?
And if it is completed first, what if another request to download that file comes in before the delete command is carried out? Is that request queued behind the delete command or is it carried out parallel to other commands so that it is begun before the delete comes into effect, effectively keeping on blocking it.
On my desktop computer I cannot delete a file that is in use. Do web servers differ?
If the platform is Windows you can't delete the file.
if the platform is Unix- or Linux-based you can delete the file: however it remains in existence while it is open, which includes while it is being transmitted.
I'm not aware of any operating system where you are notified that a file you have open has been deleted, which is the only mechanism that could possibly cause transmission to be cancelled.
I have configured hardware(juniper) to software VPN(openswan) tunnel. I want to make openswan highly available.
I was wondering if i can configure openswan cluster, but I didn't find anything substantial regarding that. How should i make my openswan highly available so that if one node goes down, the second node would be available.
You may use the left/rightupdown script to re-up the 2nd connection.
Add a line in the connection's conf file like:
leftupdown=/etc/ipsec.d/conn7up.sh
Write the bash script to re-up the other connection.
I havent tested it for a while, but it can be made to work.
Note: You need to enable DPD so that the connection would detect its state.
Thanks
Node.JS seems limited in its ability to live-update code and in its ability to automatically isolate exceptions. Both of which are practically by default in Java.
One very effective way to live-update is to have a listener process that simply echos communication to/from the child process. Then to update, the listener starts up a new child (which reads the updated code automatically) and then starts sending requests to the new child,, ending the old child when all requests are complete.
Is there already a system that provides this http functionality through stdout/stdin.
Is there a system that provides TCP server or UDP server functionaility through stdout/stdin.
By this I mean, providing a module that looks like the http or net module with the exception that it uses stdout/stdin for the underlying I/O.
Similar to This CGI module
some applications will only have to change require('http') to require('cgi')
I intend to do something similar. I hope to re-use code if it is already out there, and also to easily convert a small or single purpose webserver, into this listener layer which runs many webapps. It is important that cleanup occurs properly. Connections that end or error should be freed up and the end/error events/commands should be properly echoed both ways.
(I believe a common way is to have the children listen on ports and the parent communicate with those ports, but I think an stdout/stdin solution will be more efficient)
Use nginx (HttpUpstreamModule) or HAProxy. In both cases you'd run them in front and mark a backend as down and then bring it back up when you need to do a live upgrade.
I'm not certain that this is what you're looking for (indeed, I'm not certain that I understand your question), but Remy Sharp has written a very helpful node module called nodemon. It promises to "monitor for any changes in your node.js application and automatically restart the server." This may help with the issue of live updating code.