标签：#network

Even though networking fundamentals are often taught at the early stages of a tech career, their relevance becomes far more important when you begin working with distributed IoT and edge-driven architectures. Concepts like subnetting, routing, NAT, DNS, firewalls, and VPNs evolve from simple textbook ideas into core architectural tools that determine how devices communicate, how secure the system remains, and how reliably data moves between the edge and the cloud. This refresher looks at these fundamentals from the perspective of someone building and supporting real IoT and edge environments. The goal is not to re-teach the basics, but to reconnect them with the realities of large-scale, low-power, and cloud-connected systems. 1. Subnetting as the Backbone of IoT Network Segmentation Subnetting plays a much bigger role in IoT and edge-driven environments than most people realize. In traditional networking, subnets help organize traffic and reduce broadcast noise. In IoT, they become a core part of the system architecture. When you’re dealing with sensors, gateways, and edge compute nodes running side by side, the network must be segmented in a way that keeps each function secure and predictable. A typical LoRaWAN setup shows this clearly. The gateway LAN, the packet-forwarder network, and the edge analytics node usually sit in different subnets. This separation allows you to apply strict ACLs around what each component can communicate with, especially because IoT devices often have limited security controls of their own. Subnetting also helps manage traffic flow, ensuring that noisy sensor broadcasts don’t interfere with time-sensitive edge workloads. Beyond security, good subnet design improves fault isolation. If a node misbehaves, the impact is contained within its segment. This structure also supports multi-tenant IoT deployments, where different applications or departments share the same physical infrastructure without touching each other’s data paths. In short

Every messenger you use has a hidden dependency: a working network path to a datacenter. Drop into a basement, a packed stadium, a moving train through a tunnel, an exam hall with jammers, or a remote area with no plan, and the app is just a spinner. The people you want to reach are often standing a few meters away, but your message still has to travel to a server on another continent and back. When that path is gone, so is the app. Kabootar is my attempt to remove that dependency entirely. It is a messenger with no backend at all. Your phone forms a peer-to-peer mesh with other phones nearby, and messages hop device to device over Bluetooth and Wi-Fi until they reach the recipient. No internet, no servers, no SIM. It is built in Flutter, and the routing core is plain Dart. The core idea: delay-tolerant networking The insight that makes this work is refusing to assume the recipient is reachable right now . Normal networking is connection-oriented: open a path end to end, then send. If there is no path, there is no delivery. Kabootar instead treats the network as a delay-tolerant network (DTN). A message does not need a live end-to-end path at the moment you hit send. It needs a chain of carriers that will exist over time . You hand your message to whoever is nearby. They hold onto it, carry it as they walk around, and pass it along to the next phone they meet. Eventually a carrier bumps into the recipient and the message lands, even if that is minutes later and both you and the recipient have long since walked away. This is store-and-forward, the same shape as a durable, at-least-once message queue, except the queue is running across a swarm of phones instead of inside a datacenter. How a message actually travels The routing strategy is epidemic routing: flooding. When you send a message, it spreads to everyone in range like a rumor. Each device that receives it re-broadcasts it onward, so the message replicates through the crowd, taking every path at once. That red

If your AWS bill has a NAT Gateway line, you are paying twice for the same packet: once for the gateway to merely exist, and again for every gigabyte it carries. The fix for most teams is dull and free. Add an S3 and a DynamoDB gateway endpoint, route the heavy traffic away from NAT, and only then argue about anything fancier. That single change is free to turn on, takes minutes, and stops the most expensive traffic from ever touching the meter. This is a playbook, not a lecture. The trick with NAT Gateway pricing is that the two charges hide in different places on the bill, so most teams only ever see half of it. Numbers first, then the fixes, in the order I would actually do them. What you are actually being charged for NAT Gateway has two charges, and people forget the second one until they read the bill closely. Hourly charge — you pay for every hour the gateway is provisioned and available, whether or not a single byte moves through it. In us-east-1 (N. Virginia) and us-east-2 (Ohio) this is $0.045 per NAT Gateway-hour . That is roughly $32.85 a month per gateway just to keep the lights on. Partial hours bill as full hours. Data processing charge — you pay $0.045 per GB processed through the gateway, in the same region, on top of the hourly charge. This applies to every gigabyte, inbound or outbound, regardless of source or destination. And then there is the part the pricing page mentions almost in passing: standard AWS data transfer charges still apply on top. NAT processing is an extra meter on traffic you were already paying to move. The hourly charge is fixed and visible. The per-GB charge is the one that catches teams out, because it scales with traffic you mostly cannot see: package installs, container image pulls, S3 reads from private subnets, telemetry shipped out, cross-region calls. The rate varies by region (it runs higher in places like São Paulo, where both the hourly and per-GB rates sit around $0.093), so check your own region rather than trusti

Adapted from my original Japanese article , with AI-assisted translation and editing. My manager: “Test this device.” (Doesn't really know the product or the technology.) Me: “Sure.” (Also doesn't really know the product or the technology.) If you've worked in infrastructure, that may sound familiar. I'm Goda, a network engineer sharing things I learned while figuring out the job. SNMP comes up in a lot of network device testing. For a while, my idea of an SNMP test was simple: Run snmpwalk . Watch a pile of OIDs and values scroll past. Mark SNMP as working. A screen full of output is reassuring. It certainly looks like something is being monitored. Then I was asked to write a test plan for a device. I added an item along the lines of “Confirm that information can be retrieved using SNMP” and sent it for review. The feedback was: Which OIDs will you use for CPU and memory? The customer will probably ask. You should at least cover those. That was when it clicked: a successful walk and successful retrieval of the metrics we need are two different things. My other thought was, “Fine, you write the test plan, then.” But the feedback was fair. Getting something back is not the same as getting what you need. What did the successful walk actually prove? snmpwalk is useful. Net-SNMP's tool uses GETNEXT requests to walk through a subtree starting from a specified OID. Net-SNMP manual If it successfully returns values, you've established that you could read those values under those test conditions . That matters. It does not, by itself, establish that your CPU and memory monitoring requirements are satisfied, or that every required OID is available. I had been treating a successful command as a much broader result than it actually was. Break “SNMP testing” into specific checks Today, I'd separate at least these questions: Question What to check Can I communicate over SNMP? Whether the device responds to the intended request under the defined conditions Can I monitor CPU? The

Yash K Saini — Engineer, building in public — AI/ML, low-level (Rust/C/C++), and open source. GitHub...

Ev Ağı Nasıl Çalışır? Bir ev ağını en basit haliyle şöyle düşünebiliriz: Internet │ ISP ağı │ Ev Router'ı │ ┌─────────────┼─────────────┐ │ │ │ Laptop Telefon NAS Ev router'ı burada iki farklı dünyayı birbirine bağlar: ISP üzerinden ulaştığı dış ağ ve evdeki cihazların bulunduğu yerel ağ. Bu basit topolojinin arkasında LAN, WAN, subnet, DHCP, routing, NAT, firewall, bridge ve VLAN gibi kavramlar birlikte çalışır. 1. Ev ağı, ISP ve internet tarafı LAN ve WAN LAN — Local Area Network , router'ın yerel ağ tarafıdır. Evdeki laptop, telefon, NAS, televizyon gibi cihazlar genellikle bu tarafta bulunur. Örneğin router'ın LAN adresi: 192.168.1.1/24 olsun. Cihazlar da: Laptop 192.168.1.20 Telefon 192.168.1.30 NAS 192.168.1.50 adreslerini kullanabilir. Bunların tamamı aynı: 192.168.1.0/24 yerel IP ağına aittir. WAN — Wide Area Network ise router'ın kendi yerel ağı dışındaki bir upstream ağa bağlandığı taraftır. Tipik bir evde: Internet / ISP │ WAN │ Router │ LAN │ Ev cihazları şeklinde görünür. LAN ve WAN, Ethernet kablosunun fiziksel türünü tanımlamaz. Aynı standart Ethernet bağlantısı bir router için LAN, başka bir router için WAN rolünde olabilir. Örneğin: Internet │ Upstream Router LAN: 192.168.1.1 │ │ Ethernet ▼ Downstream Router WAN: 192.168.1.50 LAN: 192.168.10.1 Buradaki 192.168.1.0/24 ağı: upstream router açısından LAN, downstream router açısından WAN tarafıdır. Dolayısıyla LAN ve WAN kavramları hangi router açısından baktığımıza göre anlam kazanır . Upstream ve downstream Ağda internet veya daha üstteki ağa doğru olan yön upstream , son kullanıcı cihazlarına doğru olan yön ise downstream olarak adlandırılır. Internet │ Upstream Router │ Downstream Router │ Laptop Downstream router'ın internete doğru bağlandığı router onun upstream router'ıdır. Bu terminoloji özellikle evde bir modem/router arkasına ikinci bir router bağlandığında kullanışlı hale gelir. ISP'nin rolü ISP — Internet Service Provider , ev ağını daha büyük internet altyapısına bağlayan servis sağlayıcıdı

When building an online game in Unity, the question is often framed as: Should I use Photon, Netcode for GameObjects, FishNet, or Mirror? That question is too small. In 2026, there is still no single networking product that is optimal for every Unity game. The real decision is a stack : transport, netcode, authority model, session management, server hosting, and backend services. For a GameObject-based action game that needs client prediction, Photon Fusion 2.1 is a strong first PoC baseline . If your priorities are Unity Gaming Services, DOTS/ECS, self-hosting, source access, or deterministic simulation, the starting point changes. This article explains how to make that decision in production terms: latency, cheating, reconnection, hosting, bandwidth, operations, and total cost. This article uses official documentation checked on August 31, 2026 as its factual baseline. SDK versions, pricing, licensing, and service availability can change, so re-check them before committing a production project. What I mean by a real-time multiplayer game The target is roughly this class of game: 2–32 players in the same session continuously synchronized players, enemies, projectiles, or interactable objects input latency that directly affects game feel reconnects, host loss, and late joining that must be handled co-op action, FPS/TPS, racing, or competitive action If you only need turn-based play, leaderboards, chat, friends, or asynchronous PvP, you may not need a sophisticated state-synchronization netcode at all. A backend such as Nakama, PlayFab, or Unity Gaming Services may be the more important part of the architecture. Do not treat “networking” as one product A production multiplayer stack has at least five layers. Layer Responsibility Examples Transport Packet delivery, reliability, connection path, secure channel integration Unity Transport, Photon transport, UDP/WebSocket-based transports Netcode Replication, RPCs, input, prediction, interpolation, rollback Fusion, NGO,

The acquisition also leaves Sequoia-backed Serval as the de facto startup leader in AI IT service automation, industry watchers believe.

A startup called Mostik has a wild new approach to combining the capabilities of AI models.

Upgrading Juniper MX Networks from 100GbE to 400GbE: What Engineers Need to Know Moving a production network from 100 Gigabit Ethernet to 400 Gigabit Ethernet sounds simple on paper: Replace a 100G interface with a 400G interface and get four times the bandwidth. In a real carrier or data-center network, however, the interface is only one part of the equation. The router's forwarding silicon, switch fabric, midplane, power system, cooling, optics, software release, slot selection, redundancy configuration, and licensing can all determine whether the expected capacity is actually available. Juniper's MX240, MX480, and MX960 platforms provide an interesting example because these systems can be upgraded with newer generations of Modular Port Concentrators rather than requiring an immediate chassis replacement. One particularly useful case study is the Juniper MPC10E-15C , a Trio 5-based line card capable of supporting both 100GbE and 400GbE interfaces. This article isn't about whether you should buy a particular line card. Instead, we'll use the MPC10E-15C to examine the engineering questions that should be answered before attempting a 100G-to-400G upgrade on an existing Juniper MX network. Video Overview The video provides a short overview of the hardware. Below, we'll go deeper into the architecture and the deployment considerations that matter when integrating this class of line card into an existing MX environment. Why Moving from 100G to 400G Isn't Just a Port Upgrade Suppose an edge router has four heavily utilized 100GbE connections. At first glance, replacing those links with 400GbE interfaces appears straightforward. But consider what happens behind the physical port. Traffic entering that 400G interface must travel through several parts of the system: Interface → Packet Forwarding Engine → Fabric → Other line cards/interfaces Every component in that path needs sufficient capacity. A 400GbE optic connected to a router that cannot move 400 Gbps through its inte

Swiggy developed an in house predicted lifetime value model using more than 350 pre order features and a multi task MLP for Food and Instamart. Adding order count as an auxiliary task reduced model parameters by 63% while improving predictive performance. The pLTV signal is used with Google Target ROAS bidding to optimize customer acquisition. By Leela Kumili

Hello, I'm Maneshwar, and I'm building LiveReview — a blast-radius aware AI code review built for your business-critical systems. Star us to help devs discover the project, give it a try, and share your feedback to help improve the product. You open a video and it starts playing in about a second. Somewhere between your thumb and that first frame, your request crossed maybe fifteen different companies' equipment, possibly an ocean, and came back. Nobody coordinated it. That is the part I find genuinely strange about the internet, and it is the part most explanations skip. They tell you the internet is "a global network of networks", which is true and tells you nothing. So let's actually take it apart. There is no internet. There are 75,000 of them. The single most useful thing to understand up front: the internet is not a thing anyone built. It is roughly 75,000 independent networks that agreed on how to hand traffic to each other. Your ISP is one. Your university is one. Cloudflare is one. They own their own cables and routers, they answer to nobody in particular, and they interconnect voluntarily. Once you see it that way, every weird thing about the internet starts making sense. The whole arrangement has three parts: The edge is everything that actually wants to say something. Your phone, a laptop, a server in a rack, and increasingly a doorbell. These are called hosts or end systems , and they split roughly into clients that ask and servers that answer. The access network is your on-ramp. Fibre or cable at home, the office network, 5G from your pocket. Its only job is getting you to the first router. It is also, almost always, the slowest part of the entire journey, which is worth remembering next time you blame a website for being slow. The core is the mesh in the middle. Routers and the links between them, and nothing else. No control room, no master server, no company that owns it. Nobody reserved you a line Here is where the design gets clever. Before the in

Introduction When you're scaling infrastructure or managing network security, proxies become essential tools—but they solve fundamentally different problems. A reverse proxy sits between your users and your backend servers, while a forward proxy sits between your users and the internet. This distinction might sound academic, but it shapes your entire architecture: from load balancing and security posture to compliance requirements and cost structures. Choosing the wrong proxy type can lead to bottlenecks, security vulnerabilities, or unnecessary infrastructure complexity. This article walks you through real-world scenarios, pricing considerations, and decision frameworks to help you deploy the right solution. Forward Proxies: Controlling Outbound Traffic What Forward Proxies Do A forward proxy intercepts requests from your internal network and forwards them to external servers on the internet. From the external server's perspective, the proxy is the client—the real origin of the request is masked or modified. Common use cases include: Employee internet access control : A company deploys a forward proxy so IT can block malicious domains, filter content, and enforce acceptable use policies Data residency compliance : A financial services firm routes all outbound API calls through a forward proxy in a specific geographic region to meet regulatory requirements Web scraping at scale : When extracting data from multiple websites, forward proxies rotate request sources to avoid IP-based blocking DDoS mitigation for outbound traffic : Distributed request aggregation through a forward proxy can reduce fingerprinting risks Pricing and Infrastructure Costs Forward proxies typically charge per: Concurrent connections : Enterprise solutions like Zscaler or Palo Alto Networks start around $5–15 per user/month Data transferred : Cloud-based forward proxies charge $0.05–$0.30 per GB, depending on geography and provider IP rotation : Proxy services offering residential IPs (for non-

In exchange for free stuff, devices make home connections part of a proxy network.

If you ask most people where to start in DevOps or cloud engineering, you'll get answers like "learn Docker" or "get AWS certified." Almost nobody says "learn networking first," and that's a mistake — because every one of those tools sits directly on top of networking concepts, and skipping it means you're memorizing commands without understanding what they actually do. I hit this wall myself. I could docker run things and get a VPC "working" by copy-pasting a tutorial, but the moment something broke — a container that couldn't reach another container, a service that was unreachable from outside a cluster, a security group that silently ate my traffic — I had no mental model to debug with. So I went back and actually built one, layer by layer, from a single IP address up to how Kubernetes routes traffic across a cluster. This post is that mental model, written the way I wish someone had explained it to me first. Start With the Absolute Basics IP Address — the identifier for a device or server on a network. Every machine that wants to send or receive data needs one, the same way every house needs an address for mail to find it. DNS (Domain Name System) — the system that maps human-readable domain names to IP addresses. You type google.com , your machine asks a DNS server "what's the IP for this," and gets back something like 142.250.183.14 . Nobody memorizes IP addresses; DNS is the reason you don't have to. Ports — numbered channels on a server. A single machine can run many applications at once, and ports are how traffic knows which application it's meant for. A handful worth knowing cold: Port Service 22 SSH 53 DNS 80 HTTP (web servers) 443 HTTPS 3306 MySQL 5432 PostgreSQL 6379 Redis 27017 MongoDB If DNS gets you to the right server and the IP address gets you to the right machine, the port gets you to the right application on that machine. Subnets, Routing, and Firewalls Subnets let you divide one network into smaller, isolated segments — instead of every device

Nginx Load Balancing with DNS-Based Service Discovery on Incus Hari ini saya buat satu practical lab untuk memahami Nginx Load Balancing , DNS-based Service Discovery , dan operational logging dalam persekitaran self-hosted menggunakan Incus. Lab ini bermula dengan architecture yang simple: Client │ ▼ Nginx LB │ ├──► web01 └──► web02 Kemudian saya tambah satu DNS server supaya backend tidak perlu bergantung sepenuhnya kepada hard-coded IP address. 1. Architecture Final architecture: DNS dns / dnsmasq 10.107.109.18 ▲ │ DNS lookup: web.incus │ │ Nginx LB 10.107.109.69 │ Load Balancing ┌──────────┼──────────┐ ▼ ▼ ▼ web01 web02 web03 .100 .253 .xxx Ada dua jenis communication flow dalam architecture ini. DNS resolution Nginx LB ──────► DNS │ └── web.incus ↓ .100, .253, .xxx DNS hanya digunakan untuk mengetahui IP address backend. HTTP traffic Client │ ▼ Nginx LB │ ├────► web01 ├────► web02 └────► web03 DNS tidak membawa HTTP traffic . DNS hanya menjawab: Where is web.incus ? Nginx kemudian menggunakan IP yang diperoleh daripada DNS untuk melakukan load balancing. 2. Static / Hard-Coded Upstream Cara paling mudah untuk configure Nginx Load Balancer ialah dengan meletakkan IP backend secara terus. Contoh: upstream backend { server 10.107 .109.100 ; server 10.107 .109.253 ; } Architecture: Nginx LB │ ├──► 10.107.109.100 │ └──► 10.107.109.253 Kelebihan Simple Mudah difahami Predictable Sesuai untuk environment kecil Tidak memerlukan DNS service discovery Kekurangan Kalau tambah web03 : web01 web02 web03 Nginx configuration perlu diubah: upstream backend { server 10.107 .109.100 ; server 10.107 .109.253 ; server 10.107 .109.xxx ; } Kemudian configuration perlu divalidasi dan biasanya Nginx perlu di-reload. 3. DNS-Based Service Discovery Pendekatan kedua ialah menggunakan hostname sebagai service identity. Contohnya: web.incus DNS: web.incus ├── 10.107.109.100 ├── 10.107.109.253 └── 10.107.109.xxx Nginx tidak perlu mengetahui backend IP secara hard-coded. Contoh: resolver 10.

One of the most useful questions in network troubleshooting is also one of the simplest: Does it fail from another machine too? If a website will not load on my laptop, trying it from another computer can immediately change the investigation. If it works there, the service probably is not down. Something about my machine, DNS configuration, VPN, firewall, route, or network path is different. If it fails there too, the problem may be farther upstream. I wanted Network Doctor to be able to ask that question directly. So I added remote diagnosis over SSH. netdoc --via ideapad github.com Instead of running the diagnosis locally, Network Doctor connects to ideapad , runs the checks there, and reports the result back on my machine. Why another vantage point matters A network failure is always observed from somewhere. Suppose github.com is unreachable from my workstation. I can test DNS: dig github.com Then TCP: nc -vz github.com 443 Then TLS: openssl s_client -connect github.com:443 Maybe I inspect my routes, VPN, proxy settings, or firewall. Those tests are useful, but they all share one property: they are observing the network from the same machine. Trying the same destination from another machine gives me a new piece of evidence. Imagine this: Thelio: DNS PASS TCP 443 FAIL Ideapad: DNS PASS TCP 443 PASS TLS PASS HTTPS PASS That difference is interesting. GitHub clearly is not universally unreachable. The second machine just reached it. Now I have a much smaller problem to investigate: what is different about the path from Thelio? That is often more useful than running another five commands on Thelio. Turning that into a command Network Doctor already runs network checks as a dependency graph. For an HTTPS target, for example, it can test things such as the local interface, DNS resolution, TCP connectivity, TLS, HTTP, routing, and path MTU. Normally: netdoc github.com means: Diagnose github.com from this machine. With --via : netdoc --via ideapad github.com it becomes:

It's conference season! I already had to sit at home jealous while friends had fun at Render ATL, but it's my turn soon with Commit Your Code next week in Plano, TX. It boasts a banger lineup of speakers, which got me thinking: how do you get the absolute most out of an event like this? The number one rule is determining your goal before you step through the doors. Are you going to hang out with friends, meet new people, or hunt for a job? Each objective requires a completely different approach, prep strategy, and attire. 1. Hanging Out with Friends This is the easiest path. Wear whatever keeps you comfortable while looking relatively professional. Meet up with your crew, enjoy the sessions, and have fun. You done did it. 2. Networking and Meeting New People This is my primary goal for CYC this year. I'll fill you in on my plan. To keep from getting overwhelmed, I built a tracking spreadsheet for everyone I want to connect with. It might sound clinical, but it ensures no follow-up slips through the cracks. Here is my process: Pre-Conference Research: First, I reviewed the talk schedule and logged the speakers and session titles that caught my eye. Initial Outreach: I added columns for sending an intro message and a LinkedIn connection request. Then I sat down and message every single one of them. I had a bit of a template, but mostly just told people why their talk sounded interesting or exciting to me. It's hard to have writers block when you have a genuine interest in something. Some of them replied, some didn't, but I already feel like I have a foot in the door heading into the conference. During & After the Event: My spreadsheet includes columns for attending their talk, taking photos (speakers always need good photos of themselves on stage), posting on social media, and sending a post-event follow-up. Sounds like a lot? Because it is! Which is why its in a spreadsheet and not my pasta strainer brain. But it's about intent, respect, and appreciating someone else

Meta has detailed MTIA 300, its first in-house accelerator optimized for training ranking and recommendation models. By Matt Foster

If you've provisioned a VPC from a Terraform module without fully internalising what each piece is doing, that's fine — right up until something breaks. An instance that should be reachable isn't. A private instance can't pull a package update. And you're left checking five different resources with no clear mental model of how they connect. This post builds that mental model from the ground up. Not just definitions — the why behind each piece, so troubleshooting becomes deduction instead of guesswork. CIDR math you actually need A CIDR block is IP address / prefix length . The prefix length fixes the network portion; the remaining bits are your host space. Formula: 2^(32 - prefix) = total addresses . AWS reserves 5 per subnet (network address, VPC router, DNS, reserved, broadcast). CIDR Total addresses Usable /16 65,536 65,531 /20 4,096 4,091 /24 256 251 /28 16 11 To reverse-engineer a prefix from a required host count: round up to the next power of two, subtract the exponent from 32. Need 300 hosts? Next power of two is 512 (2⁹), so prefix = 32 - 9 = /23 . Run this before sizing any subnet that will host an autoscaling group or EKS node group. Start with /16 for the VPC itself. VPC CIDR is difficult to resize after the fact — once you have subnets, peering connections, or Transit Gateway attachments built against it, renumbering becomes a migration project. /16 costs nothing up front and avoids that corner. Subnet allocation: carving up the VPC A practical three-AZ production layout from 10.0.0.0/16 : Tier AZ-a AZ-b AZ-c Size Typical use Public 10.0.0.0/24 10.0.1.0/24 10.0.2.0/24 /24 ALB, NAT gateway, bastion Private/app 10.0.16.0/20 10.0.32.0/20 10.0.48.0/20 /20 EKS nodes, ECS, EC2 Data 10.0.64.0/24 10.0.65.0/24 10.0.66.0/24 /24 RDS, ElastiCache Reserved 10.0.128.0/17 /17 Future tiers, Transit Gateway, VPN The jump from /24 in the public tier to /20 in the app tier is intentional. ALBs and NAT gateways consume very few IPs; the app tier is where consumption scales