文本协议哪个不是常规语言?

发布于 2024-08-03 17:10:02 字数 154 浏览 3 评论 0原文

表示与文本网络协议相关的语法的常用方法是使用 ABNF。

就像任何 EBNF 相关的元语法一样,ABNF 能够描述上下文无关语法。

这些上下文无关语法可以表示非常规语言,对吗?

实现网络堆栈的常用方法是开发状态机。是否有非常规语言的文本网络协议?

The usual way to represent way the grammar associated with a textual network protocol is using ABNF.

Just like any EBNF-related meta-syntax, ABNF enables to describe context-free grammars.

These context-free grammars can represent a non-regular language, right ?

The usual way to implement a network stack is developing a state machine. Is there any textual network protocol which is not a regular language ?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

海夕 2024-08-10 17:10:02

我想您指的是“传统”基于行的文本协议。例如,任何使用 XML 的协议都不是常规的,因为 XML 不是常规语言(事实上,如果您查看单个字符的级别,XML 甚至不是上下文无关的)。在这种情况下,我真的想不出任何非常规协议。在语言语法中实现非常规的最常见方法是要求解析器能够计数,在我看来,需要这种解析消息的能力的协议将会很复杂(例如,匹配括号)或有限(例如,通过明确的计数而不是允许任意长的列表)。

使用 BNF 可能是因为它作为语法描述很容易理解,而不是因为上下文无关为您提供了任何必要的额外功能。我认为主要的好处是能够使用变量来代表常见的语法部分。如果您查看常见互联网协议规范中的 BNF,您会注意到它们实际上只使用常规语言的功能:无限制的重复、选择、可选性。

在我看来,您提到协议的状态机实现的声明听起来有些误解。它不是作为状态机实现的解析器,而是协议引擎,并且状态转换不是由输入中的单个字符或标记触发,而是由完整的消息触发。通常,协议状态机中的状态更关心通信的建立和拆除,而不是实际的通信。例如,TCP状态机有11种状态,其中只有一种足以满足连接建立状态,这是所有实际数据传输发生的状态,其余的都是关于打开和关闭连接的。 (是的,我知道 TCP 不是文本的,但它是一个众所周知的协议,具有已建立的状态机,因此它是一个很好的例子;在协议引擎级别,消息语法是文本还是文本并不重要二进制。)

I suppose you refer to "traditional" line-based textual protocols. For instance, any protocol that uses XML is not regular, since XML is not a regular language (in fact, XML is not even context-free if you look at the level of individual characters). In that case, I cannot really think of any non-regular protocols. The most common way to go non-regular in language syntax is to require the parser to be able to count, and it seems to me that a protocol that would require that kind of ability to parse the messages would just be complex (e.g., matching parentheses) or limited (e.g., by having explicit counts instead of allowing arbitrarily long lists).

The use of BNF is probably because it is easy to understand as a syntax description and not because context-freedom gives you any necessary additional power. The main benefit, I would think, is in the ability to use variables to stand for common pieces of syntax. If you look at the BNFs in common Internet protocol specifications, you'll note that they really use just features of regular languages: unbounded repetition, choice, optionality.

Your statement referring to state-machine implementations of protocols sounds to me like some misunderstanding. It is not the parser that is implemented as a state machine but the protocol engine, and state transitions are not triggered by individual characters or tokens in the input but by complete messages. And usually, the states in a protocol state machine are more concerned with establishment and tear-down of communication than the actual communication. For instance, the TCP state machine has 11 states, of which only one suffices for the connection-established state, which is where all the actual data transmission happens, and the rest are all about opening and closing the connection. (Yes, I know TCP is not textual, but it is a well-known protocol with an established state machine, so it serves as a good example; at the level of protocol engines, it does not matter whether the message syntax is text or binary.)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文