Dynamic Protocol Parse Based on a General Protocol Description Language

Abstract

Real-timenetwork protocol data are indispensable for network security analysis. However, the rapid evolution of protocol standards poses significant challenges to automated parsing and dynamic extensibility. While artificial intelligence (AI) techniques offer potential solutions, they often introduce semantic ambiguities and inconsistent results, thereby undermining parsing precision. To overcome these limitations, we propose PMDL (Protocol Model Description Language), a general-purpose protocol description language. PMDL abstracts protocols into structured sets of fields and attributes, enabling precise and unambiguous specification of protocol syntax and semantics. Based on PMDL descriptions, our execution engine dynamically instantiates and loads protocol templates on the fly, achieving accurate, automated, and dynamically extensible parsing of network traffic. We evaluate PMDL against representative tools such as Wireshark and Kelai, as well as approaches such as Nail and BIND. Experimental results demonstrate that PMDL provides concise yet expressive protocol specifications, and the execution engine achieves superior parsing throughput. Furthermore, performance evaluation using real-world HTTP, MySQL, and DNS traffic from a campus network confirms that our system robustly meets the throughput requirements of large-scale security analysis.

1. Introduction

Network traffic [1] serves as a critical window into network behavior by encapsulating complex communication information. As the carrier of data transmission, network traffic directly impacts data security through its integrity and confidentiality [2], and real-time monitoring and deep parsing of traffic are crucial for detecting security threats such as data theft and tampering [3]. Furthermore, network service providers leverage traffic collection and analysis to evaluate system loads, optimize configurations, and orchestrate load-balancing strategies [4]. For instance, load-balancing entities extract method names and parameter fields from data streams (e.g., those carrying SOAP [5]) to determine optimal routing paths. In the domain of network security, network traffic is an important data source for intrusion detection, firewall, deep packet detection, and other tools [6]. A typical application involves extracting fields such as message length and content type from HTTP headers to characterize contemporary network traffic patterns.

The ability of a protocol parser to analyze and detect network traffic is fundamentally constrained by its breadth of supported protocols and field types. Traditional protocol parsers, such as Wireshark [7] and Kelai [8], have developed a large number of high-performance and robust parsing codes. However, due to the strong specificity, difficulty in porting, or closed-source nature of these codes, they are difficult to reuse in other projects. Consequently, significant manpower and time must still be invested in redeveloping parsing programs for new projects. More critically, implementing protocol parsing through static code is inherently error-prone due to human oversight, varying programming expertise, and the inherent complexity or ambiguities within RFC specifications [9]. These factors necessitate frequent manual updates, recompilation, and redeployment cycles to maintain system accuracy. Although artificial intelligence technologies have introduced intelligence into protocol parsing, its reliance on probabilistic inference introduces inherent semantic ambiguity and uncertainty, frequently resulting in inconsistent and inaccurate outputs. Therefore, achieving convenient, dynamic, and accurate extension of parsing logic remains a significant, unresolved challenge.

To solve the above problems, we propose a method to implement dynamic protocol extension and resolution based on universal protocol description language. The main contributions are as follows:

• We have developed an automated parsing and dynamic expansion framework, accompanied by its corresponding implementation tools. This method advances the field of protocol parsing by enhancing its automation, enhances the convenience, dynamic extensibility, and accuracy of protocol parsing, and provides technical support for network traffic analysis.
• We abstract, categorize, and extract the categories of protocol information involved in each module of the protocol parsing process, which avoids the ambiguity of the protocol description language. Meanwhile, we defined a general Protocol Description Language, PMDL, and implemented the description of various protocol information based on the XML format.
• We generated the protocol template based on PMDL and designed and developed the protocol parsing engine, which ensured the accuracy of the protocol parsing results. In addition, we constructed a dynamically scalable and updatable protocol template in memory based on the description content of PMDL, and realized the parsing of various protocol data through the dynamic protocol parsing algorithm.
• The validity, simplicity, and correctness of PMDL are analyzed and verified in the experimental results. By benchmarking our PMDL against industry-standard tools, such as Wireshark [7] and Kelai [8], the experimental results demonstrate that PMDL can describe the protocol information succinctly and accurately, and the execution engine has better parsing performance, which meets the requirements of real-time security analysis.

2. Related Work

Generating parsing code from description languages is a prominent methodology for protocol analysis. This approach first defines protocol information using a structured language, and then automatically generates protocol parsing code through the implementation of a language parser based on the description content. This can effectively reduce the workload and vulnerabilities associated with statically coded protocol parsing. NetPDL [10] is an XML-based protocol description language that introduces tags such as switch, loop, and express in XML to control the parsing process, while also providing extensible syntax support. Nail [11] is a tool for parsing and generating formatted data, offering syntax that can describe file and protocol formats, and it automates the construction of secure and efficient parsing and generation code based on Hammer [12]. Experiments show that the DNS server based on Nail outperforms the widely used BIND DNS server on authoritative workloads [13]. Other notable frameworks include Narcissus [14], which provides a comprehensive library for encoding and decoding complex binary formats, and the work of Stephen McQuistin et al. [15], which formalizes RFC documents to automatically generate memory-safe Rust parsing code [16]. Furthermore, Parsley [17] extends these specifications to binary file formats like PDF and ELF, leveraging a compiler to generate corresponding Rust implementations. Critically, although many similar general-purpose protocol description languages [18,19,20,21] simplify code construction, they fail to address the challenge of dynamic extension and updating. The generated code typically exists as static interfaces for field or structure parsing, offering limited runtime flexibility. Developers must still manage the complexities of integrating this code into downstream analysis applications. Alternatively, some scholars explore hardware acceleration, using structured description methods to define matching and filtering strategies for protocol fields and implementing configurable parsing flexibility at the switch or router level via Field Programmable Gate Array (FPGA). For instance, Ke Wang et al. [22] proposed a method using FPGA for packet parsing and protocol management, with experiments showing that this method can flexibly extend new protocol parsing rules at the end of the protocol parsing tree while ensuring high throughput.

Driven by advances in artificial intelligence (AI), particularly in Natural Language Processing (NLP) [23], generating parsing code based on NLP has emerged as a novel approach to protocol analysis. This methodology typically leverages NLP to translate unstructured RFC documents into structured formats, such as the Lossless Forwarding (LF) format, to facilitate automated code construction. For example, Sage utilizes a semi-automated method to identify RFC literature and generate parsing code, effectively enhancing the quality of contextual semantic parsing through the use of pre-trained models. Ye et al. reduced the problem to identifying keyword fields from a set of aligned fields [24]. This approach is inherently probabilistic, employing random variables to represent the likelihood of specific fields being “keywords“ and constructing a joint distribution between these variables and observed data. Through probabilistic reasoning, they determine the most likely keyword fields, enabling message clustering and the recovery of protocol state machines. Ref. [24] represents a typical category of protocol reverse engineering methods based on probabilistic inference. While these methods excel at inferring protocol structures without prior knowledge, they lack deterministic constraints for ambiguous scenarios. This often leads to inconsistencies in field semantics and boundary determination—a flaw that directly undermines their core value as reliable parsers rather than mere analytical aids. Chandler et al. designed a fully automated tool called BinaryInferno [25]. The tool uses a set of detectors to infer a set of partial descriptions and then automatically integrates the partial descriptions into semantically meaningful descriptions that can be used to parse future packets with the same format. Sharma et al. proposed a framework called ’PROSPER: Protocol Specification Miner’ [26]. In their research, they delve into the application of large language models (LLMs) [27], specifically, GPT-3.5-turbo [28], to extract specifications from Internet Request for Comments (RFC) documents and automatically understand network protocols. They developed Artifact Miner, a tool for extracting diagram artifacts from RFCS. They used GPT-turbo 3.5 (chatGPT) extraction protocol automata and showed extraction results for zero and small samples. Ref. [26] deviates from learning protocol structures directly from network traffic; instead, it extracts grammatical and semantic rules from natural language text and transforms them into formal specifications. While [26] demonstrates the potential of Large Language Models (LLMs) in specification extraction, its reliance on natural language understanding makes it inherently vulnerable to semantic ambiguity, context drifting, and generative stochasticity. These factors often introduce inaccuracies or inconsistencies in critical dimensions—such as field boundaries, lengths, and conditional logic—consequently causing systemic or stochastic errors when the resulting parser is deployed in real-world scenarios. Zhan et al. introduced a feature extraction and semantic category aggregation method [29] that captures both field-level and contextual features, abstracting fine-grained semantics into aggregate categories. While the method proposed in [29] achieves high semantic labeling accuracy (e.g., F1-score), its end-to-end parsing behavior lacks consistency and fault tolerance. Specifically, identical messages may be assigned divergent semantic labels under different training sets or feature weights, leading to inconsistent parsing results. Furthermore, the approach suffers from error propagation: a single misidentified field can trigger a cascading failure across subsequent fields. Finally, it struggles with ’unknown semantics’—when encountering field behaviors absent from the training data, the system tends to perform a forced match with the closest known category rather than maintaining a necessary degree of uncertainty. Ishtiaq et al. propose an end-to-end framework, called Hermes, that can be used to automatically generate formal representations from natural language cell specifications [30]. They developed a neural selection parser, called NEUTREX, to process the text associated with the transformation and extract the transformation components. In addition, they designed a domain-specific language that translates these transformation components into logical formulas utilizing dependency parsing trees. Finally, they compile these logical formulas to generate transitions and create a finite-state machine. Their methodology exposes a fundamental vulnerability in AI-driven protocol ’parsing’ (in a broad sense): when the objective is to reconstruct a precise, deterministic behavioral model from ambiguous and informal natural language, even a minute semantic ambiguity can be amplified into structural errors at the state-machine level. Consequently, such inaccuracies can lead to a complete collapse of the effectiveness of downstream security analysis. Critically, while NLP-based approaches alleviate the burden of manual code generation, they remain in a nascent stage. Fundamentally, protocol specifications derived from natural language are highly susceptible to semantic ambiguity and structural uncertainty. Furthermore, these methods require extensive datasets for model training, and the quality of the resulting code is highly dependent on the model itself, which introduces the risk of serious security vulnerabilities [31].

3. Protocol Data Model Definition

To address the limitations of existing protocol description languages lacking comprehensive definitions of protocol information, we abstractly divide the protocol parsing program into four core functional modules. For each module, we extract and categorize the necessary protocol information required during execution. This approach ensures that the PMDL encompasses a wide range of protocol information categories.

3.1. Protocol Information Extraction

The primary processing logic of a protocol parser typically follows an iterative cycle: extraction–parsing [32]. In addition, the protocol parser executes auxiliary logic according to the specific structure of the protocol, such as substituting the analytic value of the preceding field into the judgment or calculation logic, and further executing the analytic flow control logic according to the operation results. To formalize these operations, we decompose the parsing workflow into four functional modules, as illustrated in Figure 1 and detailed below.

• Field Extraction Module. It is responsible for separating and extracting fields one-by-one based on the field types, quantities, order, and data lengths defined in the protocol. Once extracted, the fields are sequentially dispatched to the Field Parsing Module for further processing.
• Field Parsing Module. It is responsible for obtaining information such as the data type, offset, and data length of the fields. It reads the specified length of the byte stream based on the offset, parses the fields according to their corresponding data types, and outputs them as readable or program-processable data.
  A concrete example of field extraction and parsing: Processing the IPv4 header. Consider an IPv4 header (first 20 bytes): 45 00 00 3c 1c 46 40 00 40 06 b1 e6 c0 a8 00 64 c0 a8 00 01. According to the IPv4 protocol, its field structure is as

  Table 1. IPv4 protocol field structure.

  Field	Offset (Bytes)	Length	Type
  Version + IHL	0	1-byte	uint8
  Total Length	2	2-bytes	uint16
  Source IP	12	4-bytes	ipv4
  Destination IP	16	4-bytes	ipv4

  .
  Step 1: Field Extraction Module
  This module separates the raw bytes of each field from the byte stream based on the offset and length defined in the PMDL template:

  (1)

  Version + IHL: extract 1 byte starting from offset 0 → 45

  (2)

  Total Length: extract 2 bytes starting from offset 2 → 00 3c

  (3)

  Source IP: extract 4 bytes starting from offset 12 → c0 a8 00 64

  (4)

  Destination IP: extract 4 bytes starting from offset 16 → c0 a8 00 01

  At this stage, the fields are merely “sliced” out and remain in raw byte form.
  Step 2: Field Parsing Module
  This module receives the extracted byte blocks and performs semantic conversion according to the field type:

  (1)

  Version + IHL: 45 → parsed as integer 69, further decomposed into Version = 4, IHL = 5

  (2)

  Total Length: 00 3c → parsed in big-endian order as integer 60 (bytes)

  (3)

  Source IP: c0 a8 00 64 → parsed as IP address 192.168.0.100

  (4)

  Destination IP: c0 a8 00 01 → parsed as IP address 192.168.0.1

  At this point, the fields have been converted into structured, human-readable, and machine-processable data.
  This modular division is highlighted as it embodies the separation of concerns principle:

  (1)

  The extraction module focuses solely on structural positioning and is agnostic to field semantics;

  (2)

  The parsing module is dedicated to data transformation and operates independently of field positioning.

• Field Relationship Handling Module. It is responsible for executing the logic for handling relationships between fields and providing feedback to the Field Parsing Module and the Extraction Module, thereby altering the existence and attributes of the fields. For the Field Extraction Module, this is specifically reflected in the categories, quantities, and order of fields obtained during the extraction process. For the Field Parsing Module, this is specifically reflected in the data length attributes of the fields.
• Protocol Relationship Handling Module. It determines the next protocol type based on a specific identifier field in the protocol. In the current layered network model, non-application layer protocols generally define a field to identify the upper-layer protocol type and establish a mapping relationship between field values and upper-layer protocol categories. For example, when the port number of the TCP protocol is 53, it indicates that the application layer protocol is the DNS protocol.

Based on the above analysis, we summarize and categorize the types of information required by each module in the protocol parsing process. The mapping results are shown in

Table 2. Protocol Parsing Module and protocol information category mapping table.

Protocol Parsing Module	Protocol Information Categories	Specific Protocol Information Content
Field Parsing Module	Field Attribute Information	Field Name, Data Type, Data Length, Offset
Field Relationship Handling Module	Field Relationship Information	Existence Relationship, Attribute Relationship
Field Extraction Module	Protocol Structure Information	Field Type, Field Quantity, Field Order
Field Extraction Module	Flow Control Information	Branch Selection Control, Loop Control
Protocol Relationship Handling Module	Protocol Relationship Information	Protocol Identifier Field, Upper Layer Protocol Mapping Table

.

3.2. Protocol Data Model and Element Abstract Representation

To further abstract and organize diverse protocol metadata, we define a protocol data model centric to protocols and fields. It represents protocol structure information and flow control information in a simple and intuitive manner by defining structured fields. The elements of the model are as follows:

• Field ($Field$). It represents the fields defined in the protocol specification document that has actual significance. It is characterized by a set of constituent attributes and is formalized by the following expression:

  $$Field=〈Attr1,Attr2,\dots 〉.$$

  (1)
• Field Relationship $\left(FieldRela\right)$. It represents the field value association action information during the protocol parsing process, including existence relationships and attribute relationships. It consists of the indexed fields and the substituted processing flow, formalized by the following expression:

  $$FieldRela=〈Field1,Field2,\dots ,Process〉.$$

  (2)
• Attribute $\left(Attr\right)$. It is the most granular element in the model, described using a key–value pair representation to convey various information about basic fields, including field name, data type, data length, offset, and export type. The attribute value can represent field relationships, formalized by the following expression:

  $$Attr=〈Key,Value〉.$$

  (3)

  $$Attr=〈Key,FieldRela〉.$$

  (4)
• Structured Field ($Struct$). It represents the protocol flow control information, including branch selection control and loop control. It is composed of the fields involved in protocol flow control and the field relationships. To represent some complex protocol flow control, the fields involved in protocol flow control can also be structured fields, formalized by the following expression:

  $$Struct=〈Field1,Struct2,\dots ,FieldRela〉.$$

  (5)
• Protocol Relationship ($ProtocolRela$). It represents the association information between upper-layer and lower-layer protocols. It is composed of the protocol association field (Field) and the protocol mapping table (Value, Protocol), and its formula is as follows. The protocol association field (Field) and the protocol mapping table (Value, Protocol) compose the system, formalized by the following expression:

  $$ProtocolRela=〈Field,〈Value1,Protocol1〉,\dots 〉.$$

  (6)
• Protocol ($Protocol$). It represents a specific network protocol and is used to characterize various types of protocol information, including fields, protocol structure, protocol relationships, and more. Its formal definition is expressed as follows:

  $$Protocol=〈Field,Struct2,\dots ,ProtocolRela〉.$$

  (7)

4. Syntax Design of PMDL

Compared to alternative formats like JSON and YAML, XML excels as a data description language due to its intrinsic support for rigorous structuring, hierarchical depth, and extensibility. These attributes provide the semantic richness required to model complex protocol architectures, ensuring that PMDL remains both robust and flexible during parsing. A JSON-based PMDL is feasible and can significantly reduce redundancy while improving parsing speed. JSON also supports hierarchical structures and can be validated using JSON Schema (Draft 7). Binary formats (e.g., protocol buffers or ASN.1) can be used in high-performance or resource-constrained scenarios to achieve compact storage and efficient parsing. Within this architecture, a format converter can enable bidirectional transformation between XML (used for authoring) and JSON/binary formats (used for execution), thus preserving usability without sacrificing runtime efficiency. Therefore, we utilize XML format to define the syntax description rules for each element in the protocol data model, achieving a concise, accurate, and comprehensive definition of protocol information. To address the issue that existing protocol description languages struggle to describe complex protocol structures, we introduce design concepts from programming, specifically, branch and loop logic, to define four types of nestable structured fields. Additionally, PMDL’s extensible syntax supports the description of proprietary or specialized structures by incorporating external parsing logic.

4.1. Field Relationship Definition

The PMDL syntax definition uses the “$” symbol to indicate a reference to the parsed value of associated fields, enabling simple field relationship definitions. For complex field relationships, PMDL defines relationship expressions to incorporate the parsed values of associated fields into relational operation logic. Based on the differences in field relationship operation logic and results, PMDL defines the following two types of expressions:

• Boolean Relationship Expression. It represents the substitution of associated fields into Boolean operations to obtain true or false results, denoted by a pair of brackets “$\left[\right]$”. For complex Boolean expressions, the expression can also use the “&” and “|” symbols to perform logical AND and OR operations. For example, the relationship between the existence of the IPv4 Option field and the parsed value of the IHL field can be represented as follows:

  $$\left[\$IHL>5|\$IHL<10\right].$$

  (8)
• Numerical Relationship Expression. It represents the substitution of associated fields into mathematical operations to obtain numerical results, denoted by a pair of curly braces “{}”. For example, the relationship between the data length of the IPv4 Option field and the parsed value of the IHL field can be represented as follows:

  $$\left\{(\$IHL\times 4-20)\times 8\right\}.$$

  (9)

4.2. Field and Attribute Definition

PMDL uses the $〈\mathrm{filed}〉$ tag to define a basic field and employs a set of key–value pairs to define various attributes of the basic field. For example, the definition of the source port number field in the TCP protocol is as follows:

$$<\mathrm{fieldname}=“\mathrm{SrcPort}”\mathrm{type}=“\mathrm{uint}”\mathrm{bit}=“16”\mathrm{export}=“\mathrm{number}”>.$$

(10)

Table 3. Field attribute table.

Attribute Name	Description	Attribute Values and Their Meaning
bit	Define the data length of non-byte-aligned fields, measured in bits.	The attribute value for fixed-length fields is a non-negative integer. For example: bit = “4” indicates that the field length is 4 bits. The attribute value for variable-length fields is a numerical relationship expression. For example: bit = “$field * 4 ” indicates that the bit length of the field is determined by the calculated value of the formula.
byte	Define the data length of byte-aligned fields, measured in bytes.	The attribute value for fixed-length fields is a non-negative integer, while the attribute value for variable-length fields is a numerical relationship expression (similar to the example for bits).
endstr	Define the field data length by matching the defined terminating string.	The attribute value can be a matching string or a field reference value, for example, endstr = “∖ r $\setminus n$” or endstr = $StrField.
remain	Define the field data length by obtaining the remaining bit count.	True or false. Here, true indicates that the remaining bit count is used to define the data length of the variable-length field.
value	Define field variables to cache intermediate parsing results or for output.	The attribute value can be any number, string, byte stream, or Boolean.
name	Define field name.	The attribute value is a combination of 26 uppercase and lowercase letters and numbers.
type	Define the data type of the field.	int, uint, float, bool, bytes or string.
trans	Define whether the field parsing involves endianness conversion.	True or false, where true indicates that endianness conversion is performed during parsing.
jump	Define whether to skip parsing the field.	True or false, where true indicates that parsing is to be skipped.
offset	Define whether to offset the data stream pointer and parse the next field.	True or false, where true indicates that the pointer is offset and the next field is parsed.
export	Define the formatted output type of the field parsing results.	number, bool, bytes, string, mac, ipv4, ipv6 or null, where null indicates no output.

presents the complete basic field attribute table. Due to the vast number of protocol categories and the limitations of this chapter’s summary, the attribute table for the aforementioned fields may not fully describe all field attribute information. However, using key–value pairs to define fields allows for simple expansion of language functionality by adding the required attributes without significantly altering the syntax structure, thereby better supporting syntax extensibility.

4.3. Structured Field Definition

The design philosophy of PMDL is rooted in RFC standards, ensuring high semantic fidelity between the language definitions and real-world network communications. By adhering to these standards, PMDL ensures that the protocols it describes align with the actual behavior of protocols in network communications. In functional programming concepts, almost all programming languages define syntax for branch and loop control, and decades of programming and algorithm design practices have validated that branches and loops are sufficient to handle the vast majority of complex logic descriptions. Therefore, based on this comprehensive programming philosophy, PMDL proposes a scheme for defining structured fields, which are divided into two categories: branch structured fields and loop structured fields. Structured fields consist of attributes, expressions, and a collection of internal fields, dynamically controlling the parsing of the internal field collection based on the results of the expressions. This allows for the description of protocol structures and parsing processes. Additionally, structured fields can continue to define other structured fields within the internal field collection. As a result, structured fields form a recursive nested structure, effectively enhancing the flexibility of the syntax.

• Branch Structured Field. Branch structures are used to describe scenarios in a protocol where the protocol structure changes due to different field values. They consist of branch decision conditions and a collection of branches. By evaluating the branch decision conditions, a specific array of fields within a branch can be selected for parsing. Based on the differences in the expression methods of the branch decision conditions, PMDL classifies branch structured fields into switch fields and if fields.

  (1)

  The switch field consists of associated branch fields and an array of case branches, as illustrated in (1) of Figure 2. It selects the corresponding case branch by matching the parsed value of the associated field. For example, in the HTTP protocol, if the parsed value of the first field is a request method, such as “Get” or “Post”, it indicates that the subsequent fields to be parsed are part of the request branch; if it is a protocol version, such as “HTTP/1.0” or “HTTP/1.1”, it indicates that the subsequent fields to be parsed are part of the response branch.

  (2)

  The if field consists of a Boolean expression and two branches: true and false, as illustrated in (2) of Figure 2. The branch selection is made by evaluating the truth value of the Boolean expression. For example, in the IPv4 protocol, the branch decision condition for the Option field is whether the value of the IHL field is greater than 5. If $IHL>5$, the True branch is activated to parse the corresponding Option fields; conversely, if $IHL=5$, the False branch is executed (typically resulting in no action), indicating the absence of options.

• Loop Structured Field. Loop structured fields are used to describe scenarios in a protocol where the number of other fields changes due to variations in field values. They consist of a loop decision condition and a collection of loop body fields. By evaluating the loop decision condition, the number of times the fields within the loop body are parsed can be determined. Based on the differences in the expression methods of the loop decision conditions, PMDL classifies loop structured fields into for fields and while fields. Since the design philosophy is based on RFC document standards, which provide detailed specifications and structures for the definition of network protocols, even complex issues, such as deeply nested fields, can be addressed using For and While loop structures.

  (1)

  The while field uses the loop decision expressions defined by the start and end attributes to determine whether to parse the loop body. For instance, in the HTTP protocol, header field–value pairs are parsed iteratively until the terminating delimiter—two consecutive Carriage Return and Line Feed (CRLF) characters—is encountered.

  (2)

  The for field describes the number of iterations using the times attribute, as illustrated in (2) of Figure 3. A typical example is found in the DNS protocol, where the fields in the Question section repeat in a loop; the exact number of iterations is dynamically determined by the value of the Question Count field.

4.4. Protocol Relationship Definition

In the current layered network model, protocols below the application layer typically define an associated field to identify the type of upper-layer protocol. For example, in the IPv4 protocol, the associated field is the Protocol field, and a common mapping in the protocol mapping table is that when the Protocol field value is 17, the corresponding upper-layer protocol is UDP. PMDL defines two tags, $〈\mathrm{from}〉$ and $〈\mathrm{next}〉$, to describe protocol relationships. The $\mathrm{from}$ keyword describes the type of lower-layer protocol connected to this protocol and the corresponding value of the associated protocol field, while the $\mathrm{next}$ keyword indicates the associated field of this protocol. For example, the protocol relationship definition between IPv4 and TCP is as follows:

$$〈\mathrm{next}〉\mathrm{Protocol}〈/\mathrm{next}〉.$$

(11)

$$〈\mathrm{from}〉\mathrm{IPv}4/17〈/\mathrm{next}〉.$$

(12)

By using $\mathrm{from}$ and $\mathrm{next}$, the protocols at each layer are linked together, thereby constructing the protocol hierarchy as shown in Figure 4. As shown in Figure 4, the protocol hierarchy is derived from the five-layer architecture of computer networks. The protocol parsing process follows a bottom-up approach, starting from the link layer protocol and progressing to the application layer protocol. The specific upper-layer protocol is determined by the port number, which triggers the corresponding parsing template, creating a unique parsing path.

4.5. Extensibility Support

Certain flexible and highly complex fields or structures cannot be adequately defined using the intrinsic PMDL syntax rules. For example, DNS uses a domain name compression mechanism when defining query domain name fields, which is challenging to define through structured fields. PMDL provides an extensibility mechanism that allows for the definition of difficult-to-describe fields or structures by introducing external program processing logic. PMDL offers the following two types of extension syntax based on the categories of defined protocol information:

• Custom Attributes. When the parsing process of a field still meets the basic processing logic of the protocol field parsing module, but requires additional specialized processing after extracting the byte stream, custom attributes can be used to introduce external program processing flows. For example, this can include endianness conversion, bitwise AND or OR operations, or combinations of multiple processing flows. PMDL defines the $〈\mathrm{defAttr}〉$ tag to describe custom attributes, including the attribute name, processing priority, and processing logic. Its syntax definition and usage are as follows:

  $$〈\mathrm{defAttr}\mathrm{name}=“\mathrm{userAttr}”\mathrm{level}=“1”\mathrm{process}=“\mathrm{attr}.\mathrm{c}”〉.$$

  (13)

  $$〈\mathrm{field}\mathrm{name}=“\mathrm{field}”\mathrm{userAttr}=“\mathrm{attrValue}”〉.$$

  (14)
• Custom Fields: When the parsing process of a field does not conform to the processing logic of the protocol field parsing module or the definitions of PMDL, custom fields can be used to introduce a field parsing program, thereby completing the description of the parsing process for that field. Its syntax definition and usage are as follows:

  $$〈\mathrm{defField}\mathrm{name}=“\mathrm{userField}”\mathrm{process}=“\mathrm{field}.\mathrm{c}”〉.$$

  (15)

  $$〈\mathrm{userField}\mathrm{name}=``\mathrm{useFieldName}"\mathrm{export}=···〉.$$

  (16)

5. Design of PMDL Execution Engine

To overcome the limitations of traditional protocol parsing—namely, poor extensibility, high error susceptibility, and intensive manual effort—this paper introduces a memory-resident protocol template that encapsulates PMDL description logic. By updating and extending the protocol template, changes to the parsing code can be avoided. Furthermore, a dynamic protocol parsing process is designed to complete the reading of template information and the parsing of various protocol data, as illustrated in Figure 5. The execution engine is internally divided into three core functional modules: the Construction Module, the Parsing Module, and the Export Module, which are respectively responsible for protocol template construction and dynamic extension, dynamic protocol parsing, and formatted export. The execution workflow of each module is as follows:

• Construction Module: Responsible for executing the protocol template construction and dynamic extension processes.
  It instantiates a protocol template from the PMDL description, which is then handed over to the Protocol Template Repository for centralized management.
• Parsing Module: Responsible for performing dynamic parsing based on protocol templates. It first fetches the target byte stream along with its associated protocol template from the repository. It then executes the dynamic protocol parsing algorithm according to the information in the protocol template and generates a temporary result chain.
• Export Module: Responsible for executing the formatted export procedure. First, it obtains the temporary result chain produced by the Parsing Module; then, it constructs a JSON-formatted object guided by the user-defined output configuration within the PMDL and serializes it for output.

5.1. Construction Module

The construction module is responsible for executing the protocol template construction and dynamic extension processes. During the initialization phase, it maps the structured and basic fields defined in the PMDL description into specialized object-oriented structures. These objects are then managed uniformly by the protocol template library. A portion of the HTTP protocol templates is shown in Figure 6, and detailed information about the fields in the figure can be referenced in Figure 11.

During the runtime phase, the construction module employs a periodic scanning mechanism to monitor PMDL description files. Upon detecting new or modified files, the module synchronizes these updates to the protocol templates in real-time. This allows for the extension of new protocols and the updating of existing protocols, thereby avoiding issues related to recompiling and rebuilding the project due to code changes. The deployment of PMDL description files is performed by a system administrator or an automated management module and constitutes trusted configuration input to the system. PMDL files originate from trusted sources, and their integrity and correctness are ensured by external administrative procedures, similar to the management model used for Wireshark dissector rules or Snort intrusion detection rules. While the construction module performs strict syntax validation during ingestion, the defense against malicious tampering within authorized administrative domains remains outside its functional scope.

We implement a read-write lock control mechanism, which involves locking individual protocol updates and scanning operations within the protocol template library. This approach ensures that only one operation can be performed on the protocol template at any given time in a multi-concurrent scenario, effectively preventing conflicts during the updating and reading processes of the protocol templates. Furthermore, since protocol updates are typically driven by revisions to RFC standards, the update frequency is inherently low. As a result, the frequency of protocol template updates is limited, which means there will be no significant time overhead issues caused by excessive locking operations.

In this section, we evaluate three candidate locking mechanisms, as summarized in

Table 4. Evaluation of the three locking mechanisms.

Mechanism	Description	Advantages	Disadvantages	Evaluation Result
Coarse-grained Mutex (Mutex)	Use a single mutex to protect the entire protocol template library.	Simple implementation, ensures consistency.	All read operations are serialized, poor performance under high concurrency.	Rejected: Cannot meet concurrent parsing requirements in multi-threaded scenarios.
Fine-grained Locking	Use independent locks for each protocol or template.	Reduces contention, supports partial concurrency.	Complex lock management, potential deadlock risk.	Considered but rejected: High complexity with limited benefit.
Read-Write Lock (rwlock)	Allow multiple reader threads to access concurrently, while write operations are exclusive.	Suitable for read-intensive workloads, low read overhead.	Write operations may starve if readers are frequent.	Adopted: Achieves optimal balance between performance and safety.

. We further elaborate on the rationale for selecting the read-write lock as the optimal solution for our system.

We adopt a POSIX-compliant read-write lock (e.g., pthread_rwlock_t), for the following reasons:

• Read-Dominated Workload: As discussed in Section 5.1 of this paper, updates to protocol templates are typically triggered by RFC revisions and occur infrequently. In contrast, parsing threads frequently read templates to process incoming traffic, forming a classic “read-heavy, write-light” scenario. Read-write locks allow multiple reader threads to proceed concurrently, significantly improving parsing efficiency.
• Prevention of Update Conflicts: As stated in this paper, “by locking update and scanning operations on individual protocols within the protocol template library, we ensure that only one type of operation—either update or scan—can be performed on a protocol at any given time under concurrent access.” The read-write lock naturally supports this semantics: write operations are exclusive, while read operations are shared.
• Consistency Guarantee: The loading, validation, and replacement of a new template are performed under the protection of a write lock. This ensures that parsing threads never observe a partially updated or inconsistent template state.
• Low Overhead: Reader threads acquire the lock in shared mode, which is typically a lightweight atomic operation, imposing minimal performance overhead on the data processing path.

To ensure rapid protocol support and optimal resource utilization, the execution engine adopts an on-demand loading strategy for template management. Upon system startup, only the core parsing engine is loaded, while all potential protocol templates are not preloaded. When network traffic arrives, the engine first identifies the protocol type is identified using methods such as port numbers, protocol signature fields, or prefix pattern matching. Should the requisite parsing template not reside in memory, the system dynamically retrieves and loads the corresponding PMDL file from the external repository. After syntactic parsing, it generates an executable protocol template instance in memory. This mechanism allows the engine to adapt to protocol evolution and diverse scenarios without codebase modifications, minimizing memory overhead while fulfilling the requirements of high-performance dynamic extensibility.

5.2. Parsing Module

The parsing module is responsible for parsing the protocol data stream according to the corresponding protocol template, as shown in Figure 7. The execution engine slides over the protocol template on a field-by-field basis to read information, and then selects different processing flows based on the type of each field.

• For branch fields, the execution engine evaluates the branch decision conditions to select a specific array of fields within a branch for parsing.
• For loop fields, the execution engine determines whether to parse the array of fields within the loop body based on the results of the loop decision conditions.
• For basic fields, the execution engine has constructed a unified processing logic for attributes, as shown in Figure 8. This includes three main branch routes: parsing of ordinary basic elements (red flow), parsing of basic elements with defined value attributes (purple flow), and parsing of custom fields (blue flow), while the green flow represents the common process.

5.3. Export Module

The Export Module is designed to serialize parsing results from diverse complex structures into a JSON format—facilitating seamless integration with upper-layer analytical applications based on the provided configuration. When a data packet byte stream completes dynamic protocol parsing, a temporary result chain is generated, which is a linked list used to store C language data types. If the upper-layer analysis application wants to obtain protocol parsing information, it needs to format and export the parsing results stored in the temporary result chain into a transferable and shareable data format. As illustrated in Figure 9, structural fields are mapped to JSON objects, while basic elements are converted into supported data types according to their defined export attributes and represented as key–value pairs.

6. Experimental Analysis

6.1. Experimental Setup

PMDL is developed based on the C programming language. The experimental setup is as follows: the processor is an Intel(R) Core(TM) i7-9700 with a clock speed of 3.00 GHz and 8 cores, 32 GB of RAM, storage consists of a 2 TB SATA hard drive and a 256 GB SSD, and the operating system is Windows 11.

For experimental evaluation, a real-world traffic dataset was constructed in January 2025 by capturing mirrored egress traffic from a 10 Gbps campus network. The dataset encompasses a diverse range of standard protocols, including Ethernet, IPv4, TCP, HTTP, and DNS. To ensure suitability for performance benchmarking, the raw traffic underwent rigorous pre-processing, including protocol identification, classification, and standardization. Detailed statistics of the dataset are summarized in

Table 5. Statistics of experimental dataset.

File Name	Packet Count	Size (KB)	Size (MB)
ethernet.pcap	720,000	21,094	20.60
ipv4.pcap	468,000	22,852	22.32
tcp.pcap	295,200	20,180	19.71
http.pcap	189,699	102,492	100.09
mysql.pcap	640,000	116,075	113.35
dns.pcap	672,000	101,822	99.44

.

6.2. Validity Verification

In order to verify whether PMDL can effectively describe real-world protocols, this chapter selects representative and variable-structured protocols from various layers of the network protocol stack and defines them using PMDL. Figure 10 describes the structure definition of the fixed-length binary fields and Option fields within IPv4. The Option field consists of a list of option fields, each identified by a field value. Figure 11 presents a segment of the PMDL description for HTTP, characterized by a high density of variable-length string fields and an indeterminate number of key–value pairs. Notably, Figure 12 shows the syntax definition of the DNS query question section. Due to the domain name compression mechanism in the DNS protocol, it is difficult to define it using PMDL’s syntax rules. Therefore, a custom field approach is used to introduce external processing logic for description.

The key mechanisms in Figure 12 are as follows:

• Logical Decoupling: PMDL does not attempt to express recursive logic at the language level. Instead, it fully delegates the parsing task to an external C program via process="parseDomainName.c".
• External Implementation: The file parseDomainName.c implements the complete DNS name parsing logic, including:

  –

  Reading label length;

  –

  Detecting compression pointers (0xC0 marker);

  –

  Calculating jump offset;

  –

  Recursively or iteratively resolving pointer chains;

  –

  Concatenating the final domain name.

• Safety Control: The external C program can enforce a maximum recursion depth (e.g., 10 levels) to prevent stack overflow attacks.
• Reusability: The DomainName field can be reused across queries, responses, and resource records, improving template consistency.

The runtime flow in Figure 12 is as follows:

• The parser encounters a <DomainName …> field;
• It looks up the <defField> definition and retrieves process="parseDomainName.c";
• It invokes the pre-loaded parseDomainName() function (compiled from parseDomainN
  ame.c);
• The external function returns the parsing result (e.g., the string "www.example.com");
• The parser resumes processing subsequent fields.

To further verify whether the PMDL language is sufficiently complete, this paper compares it with protocol description languages defined in other literature. Despite the heterogeneity in methodologies and design objectives across different studies, a systematic comparison is performed based on several common evaluation dimensions. We compared nine dimensions: the completeness of data types (quantifying the support for five basic data representations: non-integral byte numbers, integral byte numbers, strings, floating-point numbers, and single-bit flags); the diversity of protocol types (binary protocols and ASCII protocols); support for variable structure in protocol definitions (if conditionals, while loops, switch statements, and for array loops); support for protocol relationship definitions; support for extensions; provision of output format syntax definitions; ambiguity (when performing protocol parsing using AI-based methods, the inherent limitations of model learning can lead to multiple possible interpretations of protocol fields or semantics, resulting in a lack of clear and unambiguous judgments. For example, the research by Zhan et al. [29] demonstrates that field identification relies on feature similarity matching. Such an inference mechanism inevitably introduces semantic ambiguity when dealing with fields characterized by overlapping meanings or complex structures. Furthermore, Ref. [30] highlights the challenges of extracting protocol logic from natural language specifications, where the inherent fuzziness of natural language leads to potential logical ambiguities in the generated Finite State Machines (FSMs).); deterministic accuracy (the potential for misclassification in AI-based log parsing. AI-based methods (e.g., [23,26]) typically treat field identification as a probabilistic problem, using stochastic variables to represent the likelihood of a field belonging to a certain type. This probabilistic reasoning is inherently antithetical to `deterministic accuracy’.); and dataset dependency (AI-based approaches heavily rely on the quality and coverage of the specific datasets used for training). The comparison results are shown in

Table 6. Functional comparison of protocol description languages.

Related Technologies	Based on the Protocol Description Language				Based on FPGA	Based on Artificial Intelligence			Our
Related Research	Nail [11]	NetPDL [10]	Narcissus [14]	Reference [16]	Reference [22]	Reference [29]	Reference [26]	Reference [24]	PMDL
The completeness of data types	√	√	√	◯	◯	√	√	√	√
The diversity of protocol types	√	√	$\mathrm{X}$	√	◯	√	√	√	√
Variable protocol structure	◯	◯	√	$\mathrm{X}$	$\mathrm{X}$	√	√	√	√
Protocol relationship definition	$\mathrm{X}$	√	√	√	◯	√	√	√	√
Syntax extensibility	$\mathrm{X}$	√	√	$\mathrm{X}$	$\mathrm{X}$	√	√	√	√
Output format definition	$\mathrm{X}$	$\mathrm{X}$	√	$\mathrm{X}$	$\mathrm{X}$	√	√	√	√
Non-ambiguity	√	√	√	√	√	$\mathrm{X}$	$\mathrm{X}$	$\mathrm{X}$	√
Deterministic accuracy	√	√	√	√	√	$\mathrm{X}$	$\mathrm{X}$	$\mathrm{X}$	√
Dataset dependency	$\mathrm{X}$	$\mathrm{X}$	$\mathrm{X}$	$\mathrm{X}$	$\mathrm{X}$	√	√	√	$\mathrm{X}$

(where √ indicates a solution with a score of 1, ◯ indicates partial resolution with a score of 0.5, and $\mathrm{X}$ indicates no solution with a score of 0).

In summary, PMDL can describe common protocols in real-world networks and possesses more extensive language features.

6.3. Simplicity Verification

When extending the parsing logic for new protocols, our proposed dynamic protocol parsing solution requires only the use of PMDL to define the new protocol, as opposed to developing protocol parsing code using a programming language. Therefore, the experiment verifies whether the PMDL syntax is sufficiently concise by comparing the workload of extending new protocols using both methods. The experiment uses LOC (Lines of Code) as a comparison metric. For protocol parsing programs, LOC refers to the number of lines of code; for PMDL, LOC refers to the number of lines in the PMDL description.

To evaluate the descriptive efficiency across diverse protocols, this paper selects several ubiquitous protocols, including Ethernet II, IPv4, TCP, HTTP (v1.0/1.1), MySQL (v4.1+), and DNS, and defines them using PMDL. For the comparative baseline, we selected the Wireshark open-source project, where each protocol’s parsing logic is encapsulated in dedicated $.\mathrm{c}$ and $.\mathrm{h}$ files, allowing for an accurate Lines of Code (LOC) count. The comparison results are shown in Figure 13. It can be seen that for the same protocol, the LOC of PMDL is significantly less than that of WireShark, with the LOC ratio ranging from 39 to 130, and for the complex MySQL description, it reaches about 8 times. These results indicate that PMDL’s syntax is remarkably concise, effectively minimizing the development workload and maintenance overhead compared to traditional general-purpose programming languages.

Developing a parser in C requires the dual expertise of both a protocol expert and a software engineer. In contrast, PMDL is a declarative language that abstracts protocols into structured collections of fields and attributes. The syntactic hierarchy of PMDL (e.g., protocol -> field -> attribute) directly mirrors the organizational structure of RFC documents. This alignment significantly reduces the cost of ’cognitive leaps’ when translating standard specifications into executable code. Furthermore, in traditional methods, protocol logic is tightly coupled with the engine code, where modifying a single field might necessitate rewriting multiple functions. PMDL achieves a complete decoupling of logic from the engine. Additionally, PMDL features dynamic loading capabilities: when a protocol standard is updated, only the PMDL text file needs modification, eliminating the need to recompile, relink, or redeploy the entire system. Equally important, compared to the hundreds of lines of C macros and complex nested loops, PMDL offers a clear structure and concise syntax (as shown in Table 2 and Table 3). This high readability ensures that new engineers can rapidly grasp the parsing logic, thereby reducing the risk of human error during long-term maintenance.

6.4. Correctness Verification

The primary objective of this experiment is to verify the expressive accuracy of PMDL and the functional correctness of the execution engine’s output. To rigorously evaluate the correctness of the parsing results for various types of fields, this chapter lists comparison items as shown in

Table 7. Dynamic protocol parsing and WireShark parsing results comparison table.

Comparison Items	Position of Comparison Items (Protocol-Mapping Number)	Comparison Results
Fixed-length basic field	IPv4-1, IPv4-2, IPv4-3	Same
Variable-length basic field	HTTP-1, Mysql-2	Same
Switch structure field	HTTP-3, Mysql-3	Same
If structure field	HTTP-4	Same
While structure field	HTTP-2	Same
For structure field	Mysql-1	Same

based on the various fields defined by PMDL. Subsequently, we select corresponding parts from the output results of Ethernet II, IPv4, HTTP, and MySQL for comparison with Wireshark. The experimental results are shown in Figure 14, Figure 15 and Figure 16, where the same comparison items are identified using rectangles and arrows of the same color. Basic fields are represented by solid rectangles, structural fields by dashed rectangles, and the criteria for determining structural fields are indicated by oval dashed boxes.

The comparison results in Table 7 indicate that the dynamic protocol parsing algorithm can correctly extract and parse fields based on the various structural fields defined by PMDL, as well as generate output results correctly according to the export attributes defined by PMDL. Therefore, the execution engine can accurately parse and output results based on the PMDL description.

6.5. Performance Analysis

• In this section, we conduct a comparative analysis using Nail and Bind, which possess representative advanced features, focusing on the complex DNS protocol. We calculate the parsing throughput by recording the number of packets processed each time and the time consumption, which is consistent with the PPS mentioned later. It can be seen from Figure 17 that the throughput of PMDL is lower than that of Nail. This is because while we are improving the dynamic scalability and semantic scalability of PMDL, we have caused certain losses in terms of throughput. As a certain degree of performance overhead is inevitable, the throughput of PMDL when parsing the DNS protocol is 23.08% lower than that of Wireshark (although PMDL’s throughput is lower than that of Nail, it is higher than that of Bind. Moreover, PMDL’s throughput also exceeds the average of Bind and Nail. Therefore, the resulting performance loss is acceptable in academic research.). One particularly prominent point is that PMDL still has significant advantages over Bind. The throughput of PMDL is nearly twice that of Bind. This indicates that the PMDL we proposed is somewhat advanced compared with other schemes. PMDL achieves an effective balance between performance and dynamic flexibility. However, in the context of single-protocol parsing where extreme speed is the primary objective, PMDL—as a dynamic interpretive engine—does not possess an absolute dominance over the pre-compiled Nail, primarily due to the intrinsic overhead of its interpretive layer. Nevertheless, this performance gap can be compensated for through multi-threaded parallelization, as illustrated in Figure 18.
• The execution engine, while implementing dynamic extension and parsing, should match the performance of traditional protocol analysis tools; otherwise, it will not meet the needs of practical application scenarios. This section selects two commonly used protocol analysis tools for comparison: Wireshark and Kelai. To assess efficiency across various layers, we selected a representative protocol stack—comprising Ethernet, IPv4, TCP, and application-layer protocols (HTTP, DNS, and MySQL)—each strictly adhering to their respective RFC specifications (e.g., RFC 791, RFC 7230). These protocols cover various structures such as fixed-length fields, variable-length fields, conditional branches, and string parsing. This chapter collects real campus network traffic for HTTP, MySQL, and DNS protocols on a mirrored traffic server and saves it as pcap files. Then, the data of different protocols within each pcap file are separated layer-by-layer and stored as corresponding pcap files. Finally, the PMDL execution engine, Wireshark, and Colasoft are used to parse each protocol’s pcap file, and the number of packets processed and the time taken for each processing are recorded to calculate the parsing throughput, i.e., packets per second (PPS), with the results shown in Figure 19.
  The experimental data in Figure 19 indicates that for the simple Ethernet II protocol parsing, the dynamic protocol parsing algorithm achieves higher throughput than Wireshark and Colasoft, as it does not need to handle inter-field relationships. The throughput of IPv4 shows a significant gap compared to Wireshark, while the throughput of TCP is roughly on a par with Wireshark. For application layer protocols, since the dynamic protocol resolution algorithm needs to frequently handle structural fields and relational expressions, its throughput is lower than that of Wireshark. Unlike Wireshark, which executes pre-compiled, static parsing logic via direct branch jumps, PMDL is designed as a declarative interpretive engine with the primary goal of providing dynamic extensibility. To maintain a deterministic guarantee without the need for recompilation, the engine must perform atomic-level attribute validation and runtime expression evaluation for every field defined in the PMDL template. Specifically, for each structured field, the engine triggers a high-density processing cycle: this involves retrieving variables from the parsed-field pool, calculating complex associative dependencies (e.g., length or existence logic), and updating the global parsing state in real-time. Although this mechanism introduces more frequent logical operations compared to Wireshark’s implicit execution paths, it represents a critical computational cost necessary to achieve unambiguous specification and on-the-fly protocol adaptation in complex network environments. (In practical applications, the advantages of PMDL in dynamic scalability and semantic scalability are beyond doubt; a certain degree of performance overhead is inevitable for PMDL. Compared to Wireshark, the throughput of PMDL is approximately 41.5% lower for HTTP, 37.9% lower for MySQL, and 29.16% lower for DNS.).
  To provide a deeper analysis of runtime performance, we conducted a systematic evaluation comparing PMDL with traditional parsers (Wireshark and Kelai). The resource consumption profile—specifically, CPU utilization and memory footprint—was comprehensively analyzed across a spectrum of representative protocols (Ethernet, IPv4, TCP, HTTP, and DNS), as illustrated in Figure 20 and Figure 21. In these figures, the horizontal axis lists the tested protocol types, while the vertical axis shows the CPU usage and memory footprint of each parser under identical test conditions.
  We analyzed the experimental results in terms of memory footprint and CPU usage. In terms of memory footprint, PMDL’s memory usage is slightly higher than that of Wireshark, primarily because PMDL needs to maintain metadata structures of protocol templates and dynamic parsing contexts at runtime to support flexible protocol extension. However, its memory overhead is comparable to that of Kelai, with no significant increase. Regarding CPU usage, PMDL’s utilization is notably lower than that of Kelai and close to that of Wireshark. This is attributed to PMDL’s efficient template-driven parsing mechanism and lightweight runtime scheduling, indicating high computational efficiency when processing packets.
  To further analyze the performance differences between the dynamic protocol parsing algorithm and Wireshark, this chapter implemented a use case program for parallel execution of dynamic protocol parsing based on the $〈\mathrm{pthread}.\mathrm{h}〉$ multithreading library in a Windows environment. The parallelism was then adjusted to parse the pcap files collected in the previous experiment and calculate the throughput. Figure 18 shows the throughput of the execution engine processing offline pcap files for the five protocols, IPv4, TCP, HTTP, MySQL, and DNS, using 1, 2, 4, and 8 threads on the host.
  The results in Figure 18 indicate that the performance of the dynamic protocol parsing algorithm scales linearly at parallelism levels of 2 and 4. With two threads, the dynamic protocol parsing throughput reaches or exceeds that of Wireshark. This suggests that the performance gap between the dynamic protocol parsing algorithm and the Wireshark tool can be mitigated by adding a small number of threads, and the performance loss incurred by the execution engine in implementing dynamic extension and parsing is within an acceptable range.
• Comparison of template update latency with recompilation in traditional parsers.
  In traditional parsers, protocol logic is statically embedded within the parser’s core. This implementation (typically in C/C++) is compiled into machine instructions at build time, becoming tightly coupled with the executable binary. Consequently, supporting a new protocol or updating an existing one requires manual source code modification followed by a full project recompilation. This “compilation” process is complex and resource-intensive, involving multiple stages such as syntax tree construction, optimization, and target code generation. More importantly, for the newly generated binary to take effect, the entire parsing service usually must be restarted. This means that during the update, the service is interrupted, and data streams being processed may be lost.
  Theoretical Latency: Therefore, the update latency in traditional approaches is fundamentally composed of “compilation time + deployment time + restart time”. This is an offline, disruptive process with latency on the order of minutes or even longer, making it unsuitable for real-time security analysis.
  The core innovation of PMDL lies in the decoupling of protocol description from execution logic. The definition of a protocol (i.e., “what the protocol is”) is abstracted into a standalone PMDL description file (template) independent of the engine, while the parsing engine itself is a general-purpose, unchanging runtime environment. When a protocol requires an update, users merely provide a revised PMDL file. The engine’s built-in monitor periodically scans the configuration directory; upon detecting changes, it ingests the XML-based PMDL and converts it into an internal in-memory data structure. This process is essentially a lightweight configuration load, involving significantly lower computational overhead than full-scale recompilation. Crucially, by employing concurrency control mechanisms such as read-write locks, the engine achieves hot-swapping—injecting new templates into the runtime library without interrupting active parsing tasks or degrading service continuity.
  Theoretical Latency: Thus, PMDL’s update latency primarily depends on the filesystem scan interval and the speed of XML parsing. This is an online, non-disruptive process, theoretically capable of second-level latency and zero downtime.
  Therefore, through its unique architectural design, PMDL transforms protocol updates from the traditional parser’s “code-compile-restart” paradigm into a “configuration-load-hot-update” paradigm. This fundamental shift enables PMDL to achieve a qualitative leap in template update latency compared to the “recompilation” approach of traditional parsers, effectively addressing the inherent scalability bottleneck of conventional methods.

6.6. Threat Model

The security assumption of this system relies on PMDL description files being trusted configuration inputs, whose deployment is carried out by system administrators or automated management modules. Therefore, the most direct threat model arises from internal personnel with system administrative privileges. In this scenario, a malicious administrator or a compromised management account could intentionally construct and deploy tampered PMDL definition files. For example, an attacker could modify the HTTP protocol template to incorrectly parse specific fields, causing critical log information to be ignored, forged, or redirected; or inject logical vulnerabilities to trigger abnormal parser behavior, leading to resource exhaustion or even remote code execution (if underlying implementations have flaws). Since PMDL files undergo only syntactic and structural consistency validation upon loading, the system cannot determine whether their semantic intent is malicious. Thus, such carefully crafted templates—while syntactically “valid”—can pass validation and be loaded, thereby compromising the integrity and reliability of the entire parsing system.

This threat reveals a key limitation in the current design: although the system can effectively prevent non-malicious anomalies caused by configuration errors or file corruption, and ensures runtime stability through mechanisms such as read-write locks, it does not provide defense against active attacks originating from within the trust boundary. Mitigating such threats requires stronger identity authentication, access control, and configuration file integrity protection mechanisms (e.g., digital signature verification). These aspects belong to the domain of system-level security, which goes beyond the core focus of this work on dynamic protocol parsing frameworks, but they are indeed important directions for future efforts to enhance the practical security of PMDL deployments.

Furthermore, PMDL can also adopt a defensive parsing philosophy to mitigate other common protocol-based threats, such as malformed packet attacks and Parsing Denial-of-Service (DoS) attacks. This security framework is built upon three core pillars:

• Strict Boundary Enforcement: By utilizing explicit length descriptors (bit, byte, endstr), the engine performs mandatory pre-checks on the remaining payload length. Any discrepancy between the declared length and the actual length triggers an immediate deterministic drop, effectively preventing buffer overflows and out-of-bounds read attempts.
• Semantic-Level Filtering: The use of strong-typed attributes (type) and specific formats (export) constitutes a defensive layer. The engine validates data compliance during the transformation phase, ensuring that malformed traffic is intercepted before it can affect higher-level semantic analysis.
• Execution Safeguards: To prevent resource exhaustion caused by malicious loops (e.g., nested while loops), PMDL implements bounded jumps and iteration threshold mechanisms. By restricting loop counts to the range of previously parsed field values and enforcing a maximum iteration cap, the engine can effectively resist Parsing DoS attacks.

While the current design provides a certain degree of security foundation, subsequent research needs to be further deepened in the following directions:

• Formal Verification of Templates: To mathematically prove the absence of logical loopholes or ambiguous paths.
• Dynamic Resource Quota Management: To allocate CPU and memory resources more granularly across concurrent parsing tasks.
• Heuristic Detection of Complex Semantic Attacks: To identify sophisticated threats that comply with syntax but violate business logic.
• Hardware-Accelerated Parallel Defense: To maintain rigorous atomic-level validation under ultra-high throughput environments using FPGA or GPU architectures.

7. Conclusions

We have proposed a protocol description language called PMDL, which is concise, accurate, and extensible. Additionally, the execution engine designed and implemented based on PMDL can generate protocol templates according to PMDL descriptions and support dynamic extension and parsing of protocols by loading new protocol templates, effectively meeting the performance requirements for real-time protocol parsing scenarios. Experiments show that PMDL can effectively define the structure and fields of real-world protocols, and the execution engine can correctly and efficiently parse protocol data streams based on PMDL descriptions. Future work will address the current limitations in the scope of protocol analysis, where the designed syntax features may exhibit shortcomings. Specifically, we plan to enrich the syntax features and concurrently update the execution engine’s processing flow. Furthermore, we will optimize the algorithm logic to boost throughput, thereby enabling PMDL to more effectively satisfy the real-time requirements of higher-level analysis applications. Beyond PMDL refinement, we acknowledge that this study focused exclusively on network protocol analysis and did not incorporate security considerations regarding protocol content. Malicious code injection via network protocols poses critical security risks. Since checksum analysis of parsed content is a vital measure to mitigate such injections, we designate verification and analysis of parsed network protocol content as a primary future research task.