TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Linguistics, Turing Completeness, and teh lulz

29 点作者 Hitchhiker超过 13 年前

3 条评论

Groxx超过 13 年前
It sounds like, with the no-length-field part, they're saying a protocol should define <i>all</i> metadata <i>and</i> data formats? I get this from the packet portion; if skipping over the data part of a packet is bad, but churning through it to get to the close-delimiter is good, then you must be validating the data somehow.<p>Well sure, validate your data. But why is that part of the <i>packet</i> protocol? I would think it should only verify that the data is properly escaped (if it is indeed escaped - with a length field it doesn't need to be). Shouldn't the contents be validated by what's using it, and not the TCP/IP packet specification?<p>Adding a length field certainly doesn't make the protocol Turing-complete, a pushdown state machine should handle it just fine - push the length onto the stack, and iterate and decrement until it's exhausted. That even keeps it context-free (if the protocol is regular, and you just added a length field), which they claim is a safe zone.<p>--<p>They also claim that escaping is a flawed art, citing SQL injection. Is it? It seems trivial to do a trivial escape that's not flawed (not claiming CSV here, just double-quotes or something), and such an escaping act <i>must</i> be performed if you read open and close delimiters... unless your protocol is also specifying and validating the contents it's transferring, down to the very last bit, and it doesn't allow those delimiters in the data.<p>Doesn't this mean they've just claimed that arbitrary data transport protocols are all inherently flawed? And that any nested specs (ASCII in a TCP/IP packet, for instance) are inherently flawed, but single-depth ones (which could very well specify ASCII as the only data format for TCP/IP packets) aren't?<p>--<p>All in all an interesting talk, and the core message is a good one - simple, non-Turing-complete protocols are best, and perhaps should be the only protocols, because they can be validated. But I don't think I buy some of the reasoning, though I'd love to be convinced otherwise if it is indeed valid.
评论 #3405118 未加载
kabdib超过 13 年前
One of my favorite bits from Vernor Vinge's _A Fire Upon the Deep_ -<p>&#62;&#62;&#62; WARNING! The site identifying itself as Arbitration Arts is now controlled by the Straumli Perversion. The Arts' recent advertisement of communications services is a deadly trick. In fact we have good evidence that the Perversion used sapient Net packets to invade and disable the Arts' defenses. Large portions of the Arts now appear to be under direct control of the Straumli Power...<p>"Sapient net packets" seem like a really, really bad idea . . .
jiggy2011超过 13 年前
Interesting talk in the video.<p>What I'm interested in is the performance implications of context-free parsing of some arbituary data without a length field.<p>Someone asked this in the talk and a paper was referenced and she thought context free could be <i>faster</i> but I don't really have time to read it.<p>Let's say you get delimited data over a network socket and no length field. How do you know how big to make your receive buffer without losing efficiency (i.e scanning the data twice or allocating more than you need) or re-allocating and copying the buffer at some interval?