TCP was designed to support end to end connections, that is, one host communicating directly with another host. Sure, there were bridges and routers in between, but those devices didn’t touch the TCP header or the payload.
When trying to diagnose network problems one of the questions I always ask is “What is the status of the switch port that is connected to the module’s interface?” The typical answer is “I need to ask the network people”.
When you contact customer support with a problem, the typical goal is to get it resolved FAST. I have observed that in many instances the initial contact with support coordination makes a fast resolution much less likely. This blog provides some tips to help speed up problem resolution.
Lots of people have created automated processes to transfer files using FTP. There are several different ways to do this, some better than others.
In my last blog I talked about automating file transfers using FTP. There are three issues with using FTP. First, your password is sent across the network in clear text making it available to anyone with a protocol analyzer.
Traceroute can be an invaluable tool when trying to diagnose connection problems to hosts on other networks. However to be used effectively you have to understand how it works and what the output means.
“We just upgraded from a T1 (1.544 mbps) to a T3 (44.736 mbps) so why is it still taking 90 minutes to copy that file?”
When writing a network application you can use non-blocking mode or blocking mode. Non blocking mode is more flexible and required when the application has to do multiple things, like servicing multiple sockets.
In 1998 it took me three days to walk the show room floor and I was pretty sure I didn’t see everything. The last few years I’ve been doing it in 1 day and this year was no exception.
Thank goodness for regression tests. There I was, earlier this week, feeling really good about some new code that I had written and (I thought) debugged.
