Author: mattchung

  • Why all developers should learn how to perform basic network troubleshooting

    Why all developers should learn how to perform basic network troubleshooting

    Regardless of whether you work on the front-end or back-end, I think all developers should gain some proficiency in network troubleshooting. This is especially true if you find yourself gravitating towards lower level systems programming.

    The ability to troubleshoot the network and systems separates good developers from great developers. Great developers understand not just code abstraction, but understand the TCP/IP model:

    Source: https://www.guru99.com/tcp-ip-model.html

    Some basic network troubleshooting skills

    If you are just getting into networking, here are some basic tools you should add to your toolbelt:

    • Perform a DNS query (e.g. dig or nslookup command)
    • Send an ICMP echo request to test end to end IP connectivity (i.e. ping command)
    • Analyze the various network hops (i.e. traceroute X.X.X.X)
    • Check whether you can establish a TCP socket connection (e.g. telnet X.X.X.X [port])
    • Test application layer (i.e. curl https://somedomain)
    • Perform a packet capture (e.g. tcpdump -i any) and what bits are sent on the wire

    What IP address is my browser connecting to?

    % dig dev.to
    
    ; <<>> DiG 9.10.6 <<>> dev.to
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39029
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 512
    ;; QUESTION SECTION:
    ;dev.to.                IN  A
    
    ;; ANSWER SECTION:
    dev.to.         268 IN  A   151.101.2.217
    dev.to.         268 IN  A   151.101.66.217
    dev.to.         268 IN  A   151.101.130.217
    dev.to.         268 IN  A   151.101.194.217

    Is the web server listening on the HTTP port?

    % telnet 151.101.2.217 443
    Trying 151.101.2.217...
    Connected to 151.101.2.217.
    Escape character is '^]'.
    

    Each of the above tools helps you isolate connectivity issues. For example, if your client receives an HTTP 5XX error, you can immediately rule out any TCP level issue. That is, you don’t need to use telnet to check whether there’s a firewall issue or whether the server is listening in on the right socket: the server already sent an application level response.

    Summary

    Learning more about the network stack helps you quickly pinpoint and isolate problems:

    • Is it my client-side application?
    • Is it a firewall blocking certain ports?
    • Is there a transient issue on the network?
    • Is the server up and running?
  • Why all developers should learn how to perform basic network troubleshooting

    Why all developers should learn how to perform basic network troubleshooting

    (Also published on Hackernoon.com and Dev.to)

    Regardless of whether you work on the front-end or back-end, I think all developers should gain some proficiency in network troubleshooting. This is especially true if you find yourself gravitating towards lower level systems programming.

    The ability to troubleshoot the network and systems separates good developers from great developers. Great developers understand not just code abstraction, but understand the TCP/IP model:

    Source: https://www.guru99.com/tcp-ip-model.html

    Some basic network troubleshooting skills

    If you are just getting into networking, here are some basic tools you should add to your toolbelt:

    • Perform a DNS query (e.g. dig or nslookup command)
    • Send an ICMP echo request to test end to end IP connectivity (i.e. ping command)
    • Analyze the various network hops (i.e. traceroute X.X.X.X)
    • Check whether you can establish a TCP socket connection (e.g. telnet X.X.X.X [port])
    • Test application layer (i.e. curl https://somedomain)
    • Perform a packet capture (e.g. tcpdump -i any) and what bits are sent on the wire

    What IP address is my browser connecting to?

    % dig dev.to
    
    ; <<>> DiG 9.10.6 <<>> dev.to
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39029
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 512
    ;; QUESTION SECTION:
    ;dev.to.                IN  A
    
    ;; ANSWER SECTION:
    dev.to.         268 IN  A   151.101.2.217
    dev.to.         268 IN  A   151.101.66.217
    dev.to.         268 IN  A   151.101.130.217
    dev.to.         268 IN  A   151.101.194.217
    

    Is the web server listening on the HTTP port?

    % telnet 151.101.2.217 443
    Trying 151.101.2.217...
    Connected to 151.101.2.217.
    Escape character is '^]'.
    

    Each of the above tools helps you isolate connectivity issues. For example, if your client receives an HTTP 5XX error, you can immediately rule out any TCP level issue. That is, you don’t need to use telnet to check whether there’s a firewall issue or whether the server is listening in on the right socket: the server already sent an application level response.

    Summary

    Learning more about the network stack helps you quickly pinpoint and isolate problems:

    • Is it my client-side application?
    • Is it a firewall blocking certain ports?
    • Is there a transient issue on the network?
    • Is the server up and running?

    Let’s chat more about network engineering and software development

    If you are curious about learning how to move from front-end to back-end development, or from back-end development to low level systems programming, hit me up on Twitter: @memattchung

  • Building an audience: A lesson from the younger me

    When it comes to building an audience as a solo-entrepreneur, the younger me was much smarter, much more in tuned with himself. These days, I operate 95% of my life from the left side of my brain, analyzing and taking a data driven, logical approach. While necessary in many respects, I need to make more decisions using my intuition … that’s how one of my first YouTube videos published 14 years ago received over 400,000 views:

    (I admit that I feel a little embarrassed sharing the above video!)

    I was 20 years old at the time. I was getting into parkour and tricking, and after learning how to back flip, I landed the “butterfly twist”. For this martial arts move, I had practiced several hours a day — with a community of other aspiring trickers — and after many face plants and overcoming of my fears, I recorded a tutorial that I then uploaded to this thing called “YouTube”.

    Back then, the number of views did not matter to me. I was just documenting my progress, sharing with the world, and most importantly: helping others on a similar journey.

    That’s it.

    I’m sure there are more sophisticated ways to gain an audience, a more strategic approach. But, I think I’ll start with just continuing to 1) help others and 2) be part of a community of link-minded people

    So, what are some ways in which you are building and engaging with your audience?

    Come chat with me on Twitter @memattchung

     

  • My introduction in the Piazza forum for Graduate Algorithms (GA)

    My introduction in the Piazza forum for Graduate Algorithms (GA)

    At the beginning of every semester, each student is encouraged to post on the forum (i.e. Piazza), introducing themselves and answering the following questions:

    What is your name? Where do you live? Why take Graduate Algorithms? What do you hope to learn? What other OMS courses have you taken? What is something interesting about you? (Optional) LinkedIn profile

    Here’s my response:

    What is your name?

    Matt Chung

    Where do you live?  Seattle, WA

    Why take Graduate Algorithms? What do you hope to learn?

    Of course, this class is mandatory for us in computing systems specialization, so that’s a big reason. Another reason would be is that I’ve taken data structures course, but never an algorithms course. So, excited to learn more about the second half of DSA.

    What other OMS courses have you taken? 

    2 more to go!!!

    Graduate Introduction to Operating Systems (GIOS), Computer Networks (CN), Information Security (IS), High Performance Computing Architecture (HPCA), Educational Technology, Compilers, Advanced Operating Systems (AOS) Distributed Computing

    What is something interesting about you?

    I published a YouTube video 14 years ago when I was into parkour and tricking, and the video has close to 500,000 views (https://www.youtube.com/watch?v=zXrot9ShfvM).

    I took a non-linear path to becoming a software engineer at Amazon Web Services, where I currently work as a C developer building network packet processing devices for EC2 Networking.

    Most recently, I’m reevaluating my career as a software engineer at FAANG and looking to pivot (not sure where/what exactly) so I can spend more time with my wife, daughter, and our two dogs; spending more time with them has been the silver lining of all the COVID-19 lockdowns.

    (Optional) LinkedIn profile

    https://www.linkedin.com/in/matchu/

    https://blog.mattchung.me

    https://twitter.com/memattchung

  • Distributed Computing @ OMSCS over – what a ride!

    Distributed Computing @ OMSCS over – what a ride!

    Last semester, I decided to enroll in the brand spanking new Georgia Tech’s Distributed Computing course offered for the first time (as part of OMSCS) this past Spring 2021. What a ride! Learned a ton, including Lamport’s Logical Clocks, the FLP theorem, and the notorious PAXOS for consensus. Hats off to Professor Ada and the wonderful teacher assistants for delivering a rigorous and rewarding course. The lectures were top notch and the distributed systems labs (originally created at University of Washington by Ellis Michael) were challenging to say the least.

    Only 2 more semesters until graduating from Georgia Tech with my M.S. in Computer Science!

     

  • Distributed Computing CS7210 Distributed Computing – A course review

    Distributed Computing CS7210 Distributed Computing – A course review

    Distributed Computing was offered in the OMSCS program for the first time this past semester (i.e. Spring 2021) and when the course opened up for registration, a storm of newly admitted and seasoned students signed themselves up — me included. I was fully aware that I was walking into unknown territory, a bleeding edge course, and expected a lot of rough edges, of which there were many. That being said, the course is great and with some some tweaks around pacing, has the potential to be the be one of the best courses offered for students, especially those specializing in computing systems.

    Overview

    The course quality is top-notch. The lectures are intellectually challenging, the assigned readers are seminal pieces of work, and the projects really drill the theoretical concepts. Overall, depending on your programming experience, expect putting in at least 20+ hours per week (with some students reporting anywhere between 30-50 hours).

    Recommendation: If you are a seasoned engineer (with at least a couple years of programming experience under your belt) and someone who can handle ambiguity with little hand holding, then I highly recommend taking the course. But if you are just starting out in your computer science journey, then I would hold off for at least a couple semesters; take the recommended pre-requisites (i.e. graduation introduction to operating systems, advanced operating systems, computer networks) and wait until the course’s rough edges are smoothed out. As another student on omscentral pointed out, this class is “for experienced engineers, not students.”

    What to expect from the course

    Pros

    • Lectures are easy to watch and are packed in digestible ~5 minute chunks
    • Assigned readings (from first half of semester) are seminal pieces of work by famous computer scientists like Leslie Lamport and Eric Brewer
    • Skills and knowledge acquired directly apply to my career as a software engineer and computer scientist
    • Instructors and teacher assistants are extremely professional, care about the students well-being, and quite generous with the grading curve

    In this class, you’ll develop a foundation around designing and building distributed systems. You’ll understand the importance of systems keeping track of time and the different ways to implement clocks (e.g. scalar clocks, vector clocks, matrix clocks). In addition, you’ll appreciate how systems achieve consensus and being able to make trade offs between choosing different consistency models such as strict consistency, eventual consistency. You’ll end the semester with learning about the infamous CAP theorem and FLP theorem and how, as a system designer, you’ll make trade offs between consistency, availability, and the ability to withstand network partitions. Of course, you’ll eat and breathe Leslie Lamport’s PAXOS. So if any of these topics interest you, you’re in for a treat.

    Cons

    • Bleeding edge course means that there were lots of rough edges
    • Projects were very demanding, often requiring multiple hours to pass a single test worth very little towards grades
    • Triggered lots of uncertainty and desperation among students throughout the second half of the semester

    As mentioned above, this class induced a lot of unnecessary stress in students. Even for someone like me, who cares less about the actual letter grades on transcripts, felt pretty anxious (this class potentially could’ve held me back another semester, since up until the grades were actually released, I had assumed I would get a C or lower).

    Impact on mental health

    One concerned students published a post on the forum, asking if students were mentally okay:

    I just wanted to check in with everyone on here in the class. I know these projects are stressful and for me it’s been something of a mental health hurdle to keep pushing despite knowing I may very well not succeed. Hope everyone is doing ok and hanging in there. Remember no assignment is worth your sanity or mental health and though we are distanced we are all in this together.

    Anonymous Calc

    Many other students chimed in, sharing their same frustrations

    I found both of the projects very frustrating. Specially this one. I am working for last 2 weeks (spending 50+ hours in writing/rewriting) and still passing only 7/8 tests. I never had unfinished academy projects. This is the first course I am having this.

    Adam

    I couldn’t help but agree:

    Honestly, I was fairly stressed for the past two weeks. Despite loving the course — content and rigor of the project — I seriously contemplated dropping the course (never considered this avenue before, and I’m 2 courses away from graduating after surviving compilers and other difficult systems courses) as to avoid potentially receiving a non-passing grade (got an A on the midterm but its looking pretty bleak for Project 4 with only 12 tests passing). At this point, I’ve fallen behind on lectures and although there is 1 (maybe 2) days left for Project 4, I’ve decided to distance myself from the project. Like many others, I’ve poured an insane number of hours into this project, which doesn’t reflect in the points in Gradescope. I suspect both the professor and the TAs are aware of the large number of people struggling with the project and will take this all into account as part of the final grading process.

    Tips

    Programming Projects

    Here’s a list of the projects, their weight towards the final grade, and the amount allocated to each assignment.

    • Project 1 – Environment Setup – 5% – 2 weeks
    • Project 2 – Client/Server – 10% – 2 weeks
    • Project 3 – Primary/Backup – 15% – 3 weeks
    • Project 4 – PAXOS – 15% – 3 weeks
    • Project 5 – Sharded KV Store – 15% – 4 weeks

    Project 1 and 2 are a walk in the park. The final 3 projects are brutal. Make sure you start early, as soon as the projects are released. I repeat: start early. Some people reported spending over 100+ hours on the latter projects.

    Unless you are one of the handful of people who can pour in 50+ hours per week in the class, do not expect to get an A on the programming projects. But don’t sweat it. Your final grade will be okay — you just need to have faith and ride the curve. All you can do is try and pass as many tests as possible and mentally prepare for the receiving a C or D (or worst) on these assignments.

    Summary

    The course is solid but needs serious tweaking around the pacing. For future semesters, the instructors should modify the logistics for the programming assignments, stealing a couple weeks from the first couple projects and tacking them on to final projects (i.e. Primary/Backup system, PAXOS, Sharded Key-Value Store). With these modifications, students will stress out way less and the overall experience will be much smoother.

     

  • Front-yard overseeding journey

    Front-yard overseeding journey

    Our front yard needs work. About 3 weeks ago, I made my first attempt at overseeding and although a couple seeds germinated, the lawn was left with lots of bare spots.

    Several bare spots in the lawn

    So I’m taking a second stab. This time around though, I’m not just going to simply chuck seeds on top of the grass. Instead, I’m taking going to take the following steps:

    • Dethatch
    • Add topsoil
    • Plant seeds
    • Rake seeds in
    • Plant more seeds
    • Pat seeds in
    • Lay peatmoss

    Essentially, I’m following the advice of these some great YouTube tutorial videos.

    Thatch removed, soil topped off, seeds planted, peat moss planted

    As a new lawn enthusiast, I have no clue as to not whether this will work. It’s sort of an experiment. I’ve watched dozens of YouTube videos and it’s time for the rubber to meet the road. So I’ll be documenting the journey and will report back in a couple days as I continue to water the lawn. Regardless, I’m enjoying the unknown and I’m in good company:

    Metric keeping me company while I work on the lawn

  • Distributed Computing – Goodbye and thanks for the wonderful semester

    Distributed Computing – Goodbye and thanks for the wonderful semester

    I just finished Spring 2021 at Georgia Tech OMSCS and published a farewell note on the classroom’s forum (i.e. Piazza platform) and would like to share that here:

    This was one hell of a semester! Hats off to professor Ada and our great TAs — I learned a great deal about both theoretical and practical distributing computing knowledge, experiencing first hand how tweaking a retry timer by a few hundred milliseconds can make or break your day.

    But above all else, thanks to all the other students in this class, I felt extremely supported, more supported than any of the 8 courses I had previously taken in the program.

    More than once throughout the class I contemplated just throwing in the towel. The last couple projects in particular really wore me out mentally and emotionally (e.g. 10 hours troubleshooting for a one-line fix to pass one single test) and if it wasn’t for the constant support of all my peers over Piazza and Slack, I would’ve probably not only dropped from the course but the journey itself would’ve felt a lot more isolating, especially in the midst of the pandemic.

    Now, there are definitely rough edges with this course, particularly around pacing on the last couple projects. But given that this was the first semester that distributed computing was offered as part of OMSCS, I anticipated minor bumps coming into this class and have no doubts that the logistics will get smoothed out over the next couple semesters.

    Finally, for those of you graduating this semester, congratulations! Way to go out with a bang. And for the rest of us, see you next semester!

    Thanks again for all the support and let’s stay connected (contact info below). Now, time for a much needed nap after taking the final exam:

  • My first lawn seeds germinating!

    My first lawn seeds germinating!

    After watching dozens of YouTube videos on lawn care, I decided about two weeks ago to overseed the front lawn and water the grass twice a day (I really used to think that the earth would just magically nourish our yard). And up until this morning, I wasn’t entirely sure if all my effort was wasted, since it’s really difficult to spot whether or not seeds were actually germinating. On top of this daily maintenance, I’ve been also singing to them, giving them some verbal love.

    My first lawn seeds germinating 1.5 weeks later

    And this morning, about 1.5 weeks later after initial seeding, I discovered that my little seeds were starting to germinate!  Proof! Finally! I was so ecstatic that I snapped a couple photos and then bolted inside, sharing the photos with Elliott and Jess.

    I suppose this is one of the silver linings of COVID-19 and being locked down at home for the last year? I’m turning into a lawn care nut.

  • iperf3 3 and TCP maximum segment size (MSS)

    iperf3 3 and TCP maximum segment size (MSS)

    The above diagram I diagrammed illustrates the impact to a network packet when setting the maximum segment size in iperf3. With an MSS of 1436, the segment (i.e. TCP payload) ends up 1424, due to the overhead of the 12 byte TCP options.