In WMS-UTR, a third party named "百分点" (Baifendian, a Chinese big-data analytics company) requested TSG's SIP protocol logs; Geedge added a monitor policy and extended the log schema with SIP-specific fields to support the handoff.

This P19 (Pakistan) service is a pure Kafka-triggered file relay: for each Kafka record it deserializes a SysFileSync payload carrying a list of {source_oss_path, destination_oss_path} pairs alongside common_log_id, common_recv_time, common_schema_type, and processing_time -- fields matching the shared session/event-log schema used elsewhere in the MESA platform -- then HTTP-GETs each file from its source path and HTTP-POSTs it to its destination path. Distinct hosError/ossError/fileSyncError counters for the two legs (source read vs. destination write) show the two endpoints are operated as separate storage systems, one referred to in logs as "Hos" and the other as "Oss". Net effect: file objects tied to individually logged monitored sessions at the Pakistan site are relayed between storage tiers as a matter of routine pipeline operation, not just session metadata.

application.yml shows the service's entire runtime config (Kafka bootstrap servers, thread-pool sizing, HTTP client-pool tuning, etc.) is pulled live from a shared internal Nacos config server, filed under Nacos config group "Galaxy" with data-id "p19-file-sync-service" -- direct confirmation that Nacos organizes Galaxy's constituent microservices (including this Pakistan-site one) under a single logical group, consistent with the taxonomy's 40+-repo galaxy-data-platform description. Separately, KafkaConsumer.java shows the underlying Kafka bus enables SASL_PLAINTEXT authentication (PLAIN mechanism, username/password sourced from the same Nacos config) specifically when the configured broker address contains port 9094, implying at least two logically distinct Kafka listener classes (authenticated on 9094 vs. unauthenticated elsewhere) on the shared bus this file-sync pipeline consumes from.

The repo galaxy/tsg_olap/p19-file-sync-service.bundle is a dedicated, site-scoped microservice explicitly namespaced for P19 -- this corpus's Pakistan deployment codename (site_codenames: "WMS-UTR / P19: Pakistan"). Its Docker image is built under the tsg/galaxy Harbor namespace (192.168.40.153:9080/tsg/galaxy/p19-file-sync-service), and its container WORKDIR/MAINTAINER are both "galaxy", directly confirming that Galaxy (the OLAP/big-data layer documented elsewhere in this taxonomy) ships individually-built, per-customer-site production services out of its tsg_olap subtree rather than only shared library code. The pom.xml calendar version (23.09.26) pins this specific build to Sept 26, 2023.

An 'ADC Hardware Installation and Configuration Guide' (v21.11) describes a modular chassis (Switch Sled, CPU Sled) matching taxonomy's Pakistan/WMS-UTR 'ADC hardware' reference, confirming ADC is a distinct deployed hardware line -- not just a site nickname -- with its own installation documentation separate from the TSG-X/TSG-7400 line.

A thesis-project assignment for hidden-service (VPN/Proxy/Tor) identification via heterogeneous graph neural networks on flow logs sources its one day of training data from a database explicitly named 'tsg_galaxy_p19' — tying the internal TSG naming convention to the taxonomy's P19/WMS-UTR Pakistan site codename — accessed over an internal 'Information Harbor' (信息港) VPN, with ground-truth hidden-service IP labels supplied by the commercial IP-intelligence service spur.us.

At a Pakistan site (P19/MSH), Geedge identified that TCP RST-injection for a Deny action fails on asymmetric ('unidirectional') flows because the synthetic RST packet lacks GRE callid/routing context only present when both directions transit the same node. Two fixes are in progress: a dedicated third-layer packet-injection route, or a cluster-wide coordination mechanism ('SwarmKV') that syncs which policy a session matched across nodes so each node can independently inject its own side's interference packet.