Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Michael Smith 0008

dblp:44/5521-8 · DBLP profile ↗
← Back
3ranked-venue papers
0as first author
0since 2021 · last 2019
—ORCID · unresolved

Domains — the database's venue-derived domains; a paper can count in several

Computer networks · 1Software engineering, systems software and programming languages · 1Applied, interdisciplinary, general and emerging computing · 1

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Software engineering, system software, and programming languages
3 papers
Software testing · 38% Requirements engineering and software design · 31% Program verification · 31%
Computer networks
3 papers
Transport protocols and congestion control · 69% Internet architecture and protocols · 21% Network management and operations · 10%

Topics — the 8 heaviest of 9, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Transport protocols and congestion control
transport protocols
0.412019
Engineering with Logic: Rigorous Test-Oracle Specification and Validation for TCP/IP and the Sockets API · J. ACM 2019
Requirements engineering and software design › specification
executable specification
0.412019
Engineering with Logic: Rigorous Test-Oracle Specification and Validation for TCP/IP and the Sockets API · J. ACM 2019
Program verification
proof assistants
0.412019
Engineering with Logic: Rigorous Test-Oracle Specification and Validation for TCP/IP and the Sockets API · J. ACM 2019
Software testing
test oracle
0.412019
Engineering with Logic: Rigorous Test-Oracle Specification and Validation for TCP/IP and the Sockets API · J. ACM 2019
Software testing
specification-based testing
0.122006
Engineering with logic: HOL specification and symbolic-evaluation testing for TCP implementations · POPL 2006
Rigorous specification and conformance testing techniques for network protocols, as applied to TCP, UDP, and sockets · SIGCOMM 2005
Network management and operations › network testing
protocol conformance testing
0.112005
Rigorous specification and conformance testing techniques for network protocols, as applied to TCP, UDP, and sockets · SIGCOMM 2005
Internet architecture and protocols
protocol specification
0.112005
Rigorous specification and conformance testing techniques for network protocols, as applied to TCP, UDP, and sockets · SIGCOMM 2005
Automated reasoning and model checking › model checking
symbolic model checking
0.012006
Engineering with logic: HOL specification and symbolic-evaluation testing for TCP implementations · POPL 2006

Methods — techniques the papers use, named apart from their topics

symbolic model checking · 0.9operational semantics · 0.9monadic relational programming · 0.8HOL · 0.2
YearPublicationVenuePosition
2019 Engineering with Logic: Rigorous Test-Oracle Specification and Validation for TCP/IP and the Sockets API
abstract
Conventional computer engineering relies on test-and-debug development processes, with the behavior of common interfaces described (at best) with prose specification documents. But prose specifications cannot be used in test-and-debug development in any automated way, and prose is a poor medium for expressing complex (and loose) specifications. The TCP/IP protocols and Sockets API are a good example of this: they play a vital role in modern communication and computation, and interoperability between implementations is essential. But what exactly they are is surprisingly obscure: their original development focused on “rough consensus and running code,” augmented by prose RFC specifications that do not precisely define what it means for an implementation to be correct. Ultimately, the actual standard is the de facto one of the common implementations, including, for example, the 15 000 to 20 000 lines of the BSD implementation—optimized and multithreaded C code, time dependent, with asynchronous event handlers, intertwined with the operating system, and security critical. This article reports on work done in the Netsem project to develop lightweight mathematically rigorous techniques that can be applied to such systems: to specify their behavior precisely (but loosely enough to permit the required implementation variation) and to test whether these specifications and the implementations correspond with specifications that are executable as test oracles . We developed post hoc specifications of TCP, UDP, and the Sockets API, both of the service that they provide to applications (in terms of TCP bidirectional stream connections) and of the internal operation of the protocol (in terms of TCP segments and UDP datagrams), together with a testable abstraction function relating the two. These specifications are rigorous, detailed, readable, with broad coverage, and rather accurate. Working within a general-purpose proof assistant (HOL4), we developed language idioms (within higher-order logic) in which to write the specifications: operational semantics with nondeterminism, time, system calls, monadic relational programming, and so forth. We followed an experimental semantics approach, validating the specifications against several thousand traces captured from three implementations (FreeBSD, Linux, and WinXP). Many differences between these were identified, as were a number of bugs. Validation was done using a special-purpose symbolic model checker programmed above HOL4. Having demonstrated that our logic-based engineering techniques suffice for handling real-world protocols, we argue that similar techniques could be applied to future critical software infrastructure at design time, leading to cleaner designs and (via specification-based testing) more robust and predictable implementations. In cases where specification looseness can be controlled, this should be possible with lightweight techniques, without the need for a general-purpose proof assistant, at relatively little cost.
Steve Bishop, Matthew Fairbairn, Hannes Mehnert, Michael Norrish, Tom Ridge, Peter Sewell, Michael Smith 0008, Keith Wansbrough
J. ACM7
2006 Engineering with logic: HOL specification and symbolic-evaluation testing for TCP implementations
abstract
The TCP/IP protocols and Sockets API underlie much of modern computation, but their semantics have historically been very complex and ill-defined. The real standard is the de facto one of the common implementations, including, for example, the 15,000--20,000 lines of C in the BSD implementation. Dealing rigorously with the behaviour of such bodies of code is challenging.We have recently developed a post-hoc specification of TCP, UDP, and Sockets that is rigorous, detailed, readable, has broad coverage, and is remarkably accurate. In this paper we describe the novel techniques that were required.Working within a general-purpose proof assistant (HOL), we developed language idioms (within higher-order logic) in which to write the specification: operational semantics with nondeterminism, time, system calls, monadic relational programming, etc. We followed an experimental semantics approach, validating the specification against several thousand traces captured from three implementations (FreeBSD, Linux, and WinXP). Many differences between these were identified, and a number of bugs. Validation was done using a special-purpose symbolic model checker programmed above HOL.We suggest that similar logic engineering techniques could be applied to future critical software infrastructure at design time, leading to cleaner designs and (via specification-based testing using a similar checker) more predictable implementations.
Steve Bishop, Matthew Fairbairn, Michael Norrish, Peter Sewell, Michael Smith 0008, Keith Wansbrough
POPL5
2005 Rigorous specification and conformance testing techniques for network protocols, as applied to TCP, UDP, and sockets
abstract
Network protocols are hard to implement correctly. Despite the existence of RFCs and other standards, implementations often have subtle differences and bugs. One reason for this is that the specifications are typically informal, and hence inevitably contain ambiguities. Conformance testing against such specifications is challenging.In this paper we present a practical technique for rigorous protocol specification that supports specification-based testing. We have applied it to TCP, UDP, and the Sockets API, developing a detailed 'post-hoc' specification that accurately reflects the behaviour of several existing implementations (FreeBSD 4.6, Linux 2.4.20-8, and Windows XP SP1). The development process uncovered a number of differences between and infelicities in these implementations.Our experience shows for the first time that rigorous specification is feasible for protocols as complex as [email protected] We argue that the technique is also applicable 'pre-hoc', in the design phase of new protocols. We discuss how such a design-for-test approach should influence protocol development, leading to protocol specifications that are both unambiguous and clear, and to high-quality implementations that can be tested directly against those specifications.
Steve Bishop, Matthew Fairbairn, Michael Norrish, Peter Sewell, Michael Smith 0008, Keith Wansbrough
SIGCOMM5