DEV Community: Abir Moulick

The Journey of Data: How OSI and TCP/IP Models Deliver Your Messages

Abir Moulick — Mon, 19 Aug 2024 16:41:49 +0000

1. Introduction

You're sitting there with Postman open, you hit send, and boom: "hello world" pops up on your screen in milliseconds. Feels almost instantaneous, right? Like magic. But what most people don't realize is that beneath that simple interaction there's this hidden world of network processes frantically working to make it happen.

In this interconnected world, understanding how data traverses networks is paramount. The OSI and TCP/IP models provide frameworks for comprehending the complexities of network communication. These models conceptually divide the communication process into distinct layers, each responsible for specific functions.

2. The OSI Model

The OSI model, a seven-layered architecture, offers a comprehensive framework for understanding network communication. Each layer performs specific functions and interacts with the layers above and below it.

2.1 Layers of the OSI Model

Physical Layer (Layer 1): The foundation of the OSI model, the Physical layer, governs the transmission of raw bits over a physical medium. It defines electrical, optical, and mechanical specifications for data transmission.
- Protocols: Ethernet, IEEE 802.11 (Wi-Fi), Bluetooth, USB
Data Link Layer (Layer 2): Responsible for node-to-node data transfer, the Data Link layer establishes and terminates connections, ensuring reliable data transmission over the physical layer. It also manages media access control (MAC) addresses.
- Protocols: HDLC, LLDP, PPP, Ethernet, IEEE 802.11 (Wi-Fi)
Network Layer (Layer 3): The Network layer facilitates routing and logical addressing. It determines the optimal path for data packets to travel across networks using IP addresses.
- Protocols: IP, ICMP, ARP, IPsec, MPLS
Transport Layer (Layer 4): Providing end-to-end communication services, the Transport layer ensures reliable and ordered delivery of data segments. It manages segmentation, flow control, and error control.
- Protocols: TCP, UDP, SCTP, DCCP
Session Layer (Layer 5): The Session layer establishes, manages, and terminates communication sessions between applications. It handles authentication, authorization, and synchronization.
- Protocols: SIP, PPTP, L2TP, H.245, SMB, NFS, PAP
Presentation Layer (Layer 6): Concerned with data representation and formatting, the Presentation layer handles data encryption, decryption, compression, and conversion between different data formats.
- Protocols: SSL, TLS, JPEG, MPEG
Application Layer (Layer 7): The topmost layer, the Application layer, provides services for user applications to access network resources. It facilitates functionalities like email, web browsing, and file transfer.
- Protocols: SMTP, HTTP, FTP, POP3, SNMP

2.2 An Illustrative Analogy

Imagine a person (P1) needing to move from one room (R1) to another (R2). Both rooms have multiple layers with doors, each requiring a specific key. P1 collects keys from each layer in R1 before exiting. Upon reaching R2, P1 uses the collected keys in reverse order to unlock the corresponding layers and enter.

In this analogy:

P1 represents data.
Layers within rooms are OSI layers.
Doors and keys represent protocols at each layer.
R1 and R2 symbolize sender and receiver servers.

3. The TCP/IP Model

The TCP/IP model, a four-layered architecture, is the practical model upon which the Internet is built. It consolidates some layers of the OSI model while maintaining a focus on end-to-end communication.

3.1 Layers of the TCP/IP Model

Network Access Layer: Combining the Physical and Data Link layers of the OSI model, this layer handles physical transmission of data over a network, including addressing and framing.
- Protocols: HDLC, LLDP, Ethernet, IEEE 802.11 (Wi-Fi)
Internet Layer: Analogous to the OSI’s Network layer, this layer manages logical addressing and routing of data packets across networks using IP addresses.
- Protocols: IP, ICMP, ARP, IPsec, MPLS
Transport Layer: Similar to the OSI’s Transport layer, this layer provides reliable or unreliable data transmission between applications. It manages segmentation, flow control, and error control.
- Protocols: TCP, UDP
Application Layer: This layer encompasses the functionalities of the Application, Presentation, and Session layers of the OSI model. It provides services for user applications to access network resources, including data formatting, encryption, and session management.
- Protocols: SMTP, HTTP, FTP, SSL, TLS, SIP, PPTP, L2TP

4. Conclusion

The OSI and TCP/IP models are essential for understanding network communication. The OSI model provides a comprehensive theoretical framework, while the TCP/IP model reflects the practical implementation of the Internet. Both models contribute to the development and maintenance of robust and efficient networks.

Git Branch Management

Abir Moulick — Wed, 26 Jun 2024 13:38:42 +0000

Introduction

A well-structured branch management flow is crucial for handling frequent releases and immediate hotfixes efficiently. This article outlines a comprehensive branch management flow designed for regular periodic releases alongside urgent hotfixes, ensuring that features and fixes are tested thoroughly before reaching the production environment. By adopting this flow, teams can enhance collaboration, reduce integration issues, and accelerate time to market.

Branch Types

Main Branches

master branch: This is your production branch, and it should always be stable, containing the code that is currently live in Main.
develop branch: This is your main development branch where all the features, enhancements, and non-critical bug fixes are merged first. This branch is live in Testing Server and Integrated testing is performed in every merge request.

Supporting Branches

Feature branches: New features or enhancements.
- Naming convention: feature/<feature-name>
Bugfix branches: Non-critical bug fixes.
- Naming convention: bugfix/<bug-name>
Release branches: Preparation for new releases.
- Naming convention: release/vX.X.X
Hotfix branches: Critical fixes for production.
- Naming convention: hotfix/<issue>

Workflow

Regular Release Cycle (Every 14 Days)

Feature Development
1. Developers create feature branches from develop for each new feature.
2. After completion and local testing, developers will create a pull request to merge it back into develop. The branch is reviewed and then merged into develop.
Bug Fixes
1. Developers create bugfix branches from develop for each bugs.
2. After completion and local testing, developers will create a pull request to merge it back into develop. The branch is reviewed and then merged into develop.
Release Workflow
1. Every 14 days, create a release branch from develop.
2. Perform Integrated testing and any final tweaks on this branch.
3. Once it's confirmed stable, merge release into master and deploy to production.
4. Also, merge back into develop to ensure all changes are included in the next cycle.

Hotfixes (Immediate Release)

Hotfix Workflow:
1. When a critical issue is identified in production, developers create a hotfix branch directly from master.
2. Fix the issue in the hotfix branch & test thoroughly.
3. Merge the hotfix branch first into master and deploy immediately.
4. Also merge hotfix into develop to ensure the fix is included in the ongoing development.

Conclusion

Adopting a structured branch management flow, offers numerous advantages to any software development team. Implementing such a branch management strategy empowers teams to tackle frequent releases and the need for rapid responses to critical production issues. However, this strategy depends on specific needs and dynamics of the team and varies from company to company.

This is my second blog writing. Feel free to comment if you have any questions or any refinement to the article. If you like the blog, don’t forget to like it & share with your friends/colleagues.

To get in personal touch, connect me on:
Linkedin:https://www.linkedin.com/in/abirmoulick/
Github:https://github.com/Abir10101/

Thanks for reading
Written with ❤️ & passion 🔥 by Abir Moulick

SDLC without DevOps

Abir Moulick — Thu, 20 Jun 2024 01:31:34 +0000

The Software Development Life Cycle (SDLC) is a structured process that guides the creation of high-quality software. It encompasses all stages, from initial planning and requirements gathering, through coding and testing, to deployment and maintenance. This article explores the SDLC in the context of a Java application. I'll focus on SDLC stages from Development to Deployment & Monitering of the application.

Development Server: The Crucible of Innovation

Purpose: The development server is a local environment where individual developers implement features, fix bugs, and conduct initial testing.
Setup: Developers clone the code repository and install Java & JDK. The application runs in this server using development environment variables (e.g., development database credentials).
Tools: IDEs and code linters are used to ensure code quality and consistency.
Workflow: After developing and locally testing a feature, the developer pushes the code to the testing server.

Testing Server: The Bastion of Quality Assurance

Purpose: This server is dedicated to comprehensive feature testing to identify bugs and vulnerabilities before deployment.
Types of Tests:
- Unit Tests: Verify the functionality of individual components in isolation.
- Integration Tests: Check how different components interact.
- End-to-End (E2E) Tests: Simulate user flows through the entire application.
- Performance Tests: Assess how the application handles load and stress.
Setup: JDK and Maven (for building and running the application) are installed. Code is pulled from the "testing" Git branch.
QA Role: Quality Assurance (QA) teams manually test the software, focusing on usability, exploratory testing, and requirement fulfillment.
Benefits of a Separate Server:
- Long-running tests won't block developers.
- Dedicated resources for testing ensure reliability.
Next Step: After successful testing, the code is promoted to the production server.

Production Server: The Arena of Real-World Usage

Purpose: This is the live environment where end-users interact with the application. It houses the most stable code version.
Setup: Similar to the testing server, JDK and Maven are installed. Code is pulled from the "release" Git branch. The application runs in a production server environment (e.g., Tomcat) using production environment variables.
Monitoring: The application is continuously monitored. If issues arise, actions might include:
- Rolling back to a previous version.
- Assigning hotfix tasks to developers.

Conclusion

This SDLC approach can be done manually without automation but in the world of fast feature deployment we have to automate some steps and implement devops methodology. I'll be writing about automating this application setup in my future articles.

This is my first blog writing. Feel free to comment if you have any questions or any refinement to the article. If you like the blog , don’t forget to like it & share with your friends/colleagues.

To get in personal touch, connect me on:
Linkedin:https://www.linkedin.com/in/abirmoulick/

Thanks for reading
Written with ❤️ & passion 🔥 by Abir Moulick