npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2025 – Pkg Stats / Ryan Hefner

@push.rocks/smartproxy

v21.1.7

Published

A powerful proxy package with unified route-based configuration for high traffic management. Features include SSL/TLS support, flexible routing patterns, WebSocket handling, advanced security options, and automatic ACME certificate management.

Readme

Protocol Detection Reorganization Plan

Current Issues

  1. Triple Fragment Handling: Three separate implementations of fragment buffering:

    • TlsDetector.detectWithFragments()
    • HttpDetector.detectWithFragments()
    • ClientHelloParser.handleFragmentedClientHello()
  2. Overlapping Responsibilities:

    • Detectors are parsing full protocol details (ALPN, cipher suites, headers)
    • Direct coupling between detectors and protocol parsers
    • Detection and parsing are intermingled
  3. Unclear Boundaries:

    • Detection should be "what protocol?" but it's doing "parse everything"
    • SNI extraction happens in both detection and SNI handler

Proposed Reorganization

1. Simplify Detection Layer

  • Make detectors lightweight - only identify protocol type
  • Remove full parsing from detectors
  • Return minimal routing info (protocol type, maybe domain)

2. Create Shared Fragment Handler

ts/protocols/common/
�� fragment-handler.ts    # Shared fragment buffering
�� types.ts               # Common protocol types

3. Separate Detection from Parsing

  • Detection: Quick protocol identification (first few bytes)
  • Parsing: Full protocol parsing (use existing protocol parsers)
  • Routing: Extract just routing info (domain/SNI)

4. Reorganize Detection Module

ts/detection/
�� protocol-detector.ts      # Main orchestrator
�� detectors/
   �� quick-detector.ts    # Fast protocol identification
   �� routing-extractor.ts # Extract routing info only
�� utils/
    �� fragment-manager.ts  # Shared fragment handling

5. Clear Separation of Concerns

  • Protocols: Pure protocol knowledge (constants, parsers)
  • Detection: Protocol identification and minimal routing extraction
  • Handlers: Full protocol handling (SNI Handler, HTTP Handler, etc.)

Benefits

  • Eliminate duplicate fragment handling code
  • Faster detection (less parsing in hot path)
  • Clearer boundaries between layers
  • Better performance for routing decisions
  • Easier to add new protocols

Implementation Steps

Phase 1: Create Shared Infrastructure

  • [x] Create ts/protocols/common/ directory
  • [x] Implement shared fragment handler
  • [x] Define common protocol types

Phase 2: Simplify Detectors

  • [x] Create lightweight protocol identifier
  • [x] Create routing info extractor
  • [x] Update detectors to use shared components

Phase 3: Refactor Detection Module

  • [x] Update ProtocolDetector to use new architecture (created V2)
  • [ ] Remove duplicate fragment handling from old detectors
  • [ ] Clean up detector interfaces

Phase 4: Update Integration Points

  • [ ] Update RouteConnectionHandler to use V2
  • [ ] Update TlsManager to use V2
  • [x] Ensure backward compatibility (both versions exported)

Phase 5: Testing and Cleanup

  • [x] Run all tests (passing)
  • [ ] Remove deprecated code after migration
  • [ ] Update documentation

Current Status

The reorganization has been successfully implemented with a V2 architecture that:

  • Uses a shared fragment handler to eliminate duplicate code
  • Separates quick protocol detection from full parsing
  • Provides lightweight routing extraction without full protocol parsing
  • Maintains backward compatibility by exporting both V1 and V2 versions

What's Complete

  • All new V2 components are implemented and working
  • Tests are passing with the new architecture
  • Both old and new versions are available for gradual migration

Remaining Work

  1. Migration: Update integration points to use V2 detectors

    • RouteConnectionHandler
    • TlsManager
    • route-helpers.ts
  2. Cleanup: After migration is verified

    • Remove old detector implementations
    • Remove duplicate fragment handling code
    • Update all imports to use V2
  3. Documentation: Update docs to reflect new architecture