This work has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No. 644334 (NEAT). The views expressed are solely those of the author(s)Peer reviewedPreprin

Bozakov, Zdravko

Dreibholz, Thomas

Fairhurst, Godred

Grinnemo, Karl-Johan

Hurtig, Per

Khademi, Naeem

English

This work has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No. 644334 (NEAT). The views expressed are solely those of the author(s)Peer reviewe

Aberdeen University Research

A NEATWay to do Network ProgrammingKarl-Johan GrinnemoAnna BrunstromKarlstad UniversityZdravko BozakovDell EMC Research EuropeThomas DreibholzSimula Research LaboratoryGorry FairhurstUniversity of AberdeenPer HurtigKarlstad UniversityNaeem KhademiUniversity of OsloABSTRACTThere is a growing concern that the Internet transport layer hasbecome ossied in the face of emerging novel applications, andthat further evolution has become very dicult. The NEAT sys-tem introduces a novel and evolvable transport API that decouplesapplications from the underlying transport layer and network ser-vices. This paper provides an overview of the NEAT API from aprogrammer’s perspective and exemplies its use through a simpleclient application.KEYWORDSNEAT, API, event-based, transport service, transport selection1 INTRODUCTIONThe Internet is often seen as having a common network layer andtwo widely deployed transport protocols, TCP [4] and UDP [3],with other transports, such as SCTP [5], struggling to nd broaddeployment. The NEAT system [1] challenges the view of an ossi-ed transport layer by providing an API that is oblivious to specictransport protocols and instead focuses on requested transport ser-vices. Applications provide the NEAT system with trac require-ments, pre-specied policies, and measured network conditions.Based on this information, NEAT establishes and congures appro-priate connections. Through its design, NEAT enables new networkand transport functions and protocols to be added incrementallyand transparently.Figure 1 illustrates the NEAT system. Applications access NEATvia a user API. The API oers transport services similar to thoseoered by the socket API, but in an event-driven fashion. The APIinterfaces the NEAT User Module, which consitutes the main part ofthe system. The NEAT User Module is designed to be portable acrossdierent operating systems and network stacks. One of its primaryresponsibilities is to select the most appropriate transport solutionfor a requested transport service. At the core of this selection pro-cess is the Policy Manager (PM): The PM combines applicationrequirements with available transport protocols, transport-protocolparameters, and feasible transport endpoints, i.e., IP addresses andport numbers. The PM uses this information to create a list of can-didate transport solutions, sorted in order of appropriateness, touse for a requested transport service.The PM obtains informationfrom two sources: the Policy Infor-mation Base (PIB) and the Characteristics Information Base (CIB).The PIB is a repository that contains a collection of policies, whereeach policy consists of a set of rules linking a set of matchingrequirements to a set of preferred or mandatory transport charac-teristics. In contrast, the CIB is a repository storing informationUDPIPv4/IPv6ApplicationNEAT User APITCP SCTP New	TransportTCP SCTP New	TransportNEAT User Module Policy	ManagerCIBPIBFigure 1: The architecture of the NEAT system.about available interfaces, supported protocols towards accesseddestination endpoints, network properties and current/previousconnections between endpoints.This paper gives a “programmer’s view” of the NEAT system.Section 2 introduces the NEAT User API through a client applicationexample. The paper concludes in Section 3 with a brief summaryand some nal remarks on ongoing and future work on the NEATsystem.2 THE NEAT APIThe NEAT API is a callback-based, asynchronous, and non-blockingnetwork API that is intended to complement and many times re-place existing network APIs by being simpler and more exible. tis implemented using libuv [2], which provides asynchronous I/Oacross multiple platforms.The most important concept in the NEAT API is that of a ow.A ow is similar to a socket connection in the BSD API in thatit provides a bidirectional link between two applications. Also, inthe same way as a socket connection, a ow is tied to a transport-layer protocol. However, in contrast to a socket, the tie betweena ow and a transport protocol is fairly loose. In fact, a ow maybe created even without specifying a transport protocol. A ow inNEAT always belongs to a context. The context serves as a commonenvironment for multiple related ows within an application, andcomprises one libuv event loop and one DNS-resolution context.Table 1 lists the major NEAT API functions. The neat_init_ctxfunction initializes a context, and neat_new_flow creates a newow within a specied context. An application creates a ow foreach connection it wants to open, and sets the requirements im-posed on that ow through the function neat_set_property. Itcloses a ow by calling the function neat_close, and frees the con-text by invoking neat_free_ctx. The neat_open and neat_acceptANRW’17, July 2017, Prague, Czech Republic K-J. Grinnemo et al.Table 1: The primary NEAT API functionsFunction Descriptionneat_init_ctx Creates a new context.neat_new_flow Creates a new ow.neat_set_operations Sets callbacks for a ow.neat_set_property Sets the properties of a ow.neat_open Opens a ow and connects toa transport endpoint.neat_accept Listens to incoming ow requests.neat_start_event_loop Starts the NEAT event loop.neat_stop_event_loop Stops the NEAT event loop.neat_write Writes data to a ow.neat_read Reads data from a ow.neat_close Closes a ow and deallocatesassociated data.neat_free_ctx Deallocates a context.functions roughly correspond to the socket API functions connectand listen: The neat_open function creates and opens up a owtowards a specied transport endpoint, which can be either a DNSname or an IP address and port number, and the neat_accept func-tion listens for incoming ow requests on a given port. In the sameway, the neat_write and neat_read function calls correspondwith the read and write socket function calls.As mentioned, the NEAT API promotes an event-driven pro-gramming style, i.e., an application subscribes to events from theNEAT API. Callbacks in the NEAT API is registered on a per-ow ba-sis. The most important callbacks are on_connected, on_readableand on_writable. The on_connected callback is executed once aow has connected to a remote endpoint. The on_writable andon_readable callbacks are executed once data may be written toor read from a ow without blocking. Other important callbacksare on_all_written and on_error. on_all_written is invokedwhen all data sent by a previous call to neat_write has been writ-ten out on a ow. This callback is often used by applications tochange state, e.g., a client application might go from sending arequest to a server to listen for the reply. The on_error callback,as the name suggests, is called whenever an error occurs duringthe processing of a ow.Listing 1 provides a code excerpt of a client implemented inNEAT. In the main function, the program starts by initializing acontext and a ow within that context. Next, ow requirements ordesired ow properties, expressed in JSON syntax, are registered.Recall from Section 1 that NEAT combines desired ow proper-ties, policies, and information stored in the CIB when selectingan appropriate transport solution. In this example, our client tellsNEAT that it wants to establish a ow that is capable of low-latencycommunication. NEAT will try to satisfy this by having the PM com-pose a list of transport congurations, able to provide low-latencycommunication.Following the ow properties, callbacks are registered. In this par-ticular case, only one callback is registered, on_connected, whichis called as soon as neat_open has initiated a ow between itselfand a local server listening on port 5000. Note that the registrationof callbacks is not something done once and then forgotten, butsomething that is continuously revised during the progress of theprogram. In our example, this is shown in the on_connected call-back, in which callbacks for on_writable and on_all_writtenare registered.Listing 1: Simple NEAT client.#include <neat.h>...static char *properties ="{\" low_latency \": {\" value \": true ,\" precedence \": 1}}";static neat_error_codeon_connected(struct neat_flow_operations *ops) {ops ->on_writable = on_writable;ops ->on_all_written = on_all_written;neat_set_operations(ops ->ctx , ops ->flow , ops);return NEAT_OK;}static neat_error_codeon_writable(struct neat_flow_operations *ops) {...}static neat_error_codeon_all_written(struct neat_flow_operations *ops) {...}intmain(int argc , char *argv []) {...ctx = neat_init_ctx ();flow = neat_new_flow(ctx);neat_set_property(ctx , flow , properties);memset (&ops , 0, sizeof(ops));ops.on_connected = on_connected;neat_set_operations(ctx , flow , &ops);if (neat_open(ctx , flow , "127.0.0.1", 5000, NULL , 0)) {fprintf(stderr , "neat_open failed\n");return EXIT_FAILURE;}neat_start_event_loop(ctx , NEAT_RUN_DEFAULT);neat_free_ctx(ctx);return EXIT_SUCCESS;}Once callbacks have been registered and a ow request has beenissued, the NEAT event loop is initiated by callingneat_start_event_loop; the NEAT_RUN_DEFAULT parameter in theneat_start_event_loop function call tells NEAT to run in theevent loop as long as there are open ows and/or outstandingevents. Our client program ends by freeing its context and the ad-hering ows, both of which are taken care of by the neat_free_ctxfunction call.3 CONCLUSIONSThe NEAT system oers an simple-to-use yet powerful API for net-work applications that decouples them from the actual transportprotocol being used. It diers from most other network APIs in thatit explicitly enables applications to communicate their service re-quirements to the transport system in a generic, transport-protocolindependent way. This paper oers a "programmer’s perspective"on the NEAT and in so doing gives a brief overview over the NEATUser API and demonstrates its use through a simple client applica-tion. The NEAT system is at the time of writing a system in ux.Ongoing work on features such as multi-path scheduling, less-than-best eort and coupled congestion control, and integration of NEATwith SDN drives a continuous extension of the capabilities of theNEAT User API.A NEAT Way to do Network Programming ANRW’17, July 2017, Prague, Czech RepublicACKNOWLEDGMENTSThis work has received funding from the European Union’s Horizon2020 research and innovation programme under grant agreementNo. 644334 (NEAT). The views expressed are solely those of theauthor(s).REFERENCES[1] N. Khademi, D. Ros, M. Welzl, Z. Bozakov, A. Brunstrom, G. Fairhurst, K.-J. Grin-nemo, D. Hayes, P. Hurtig, T. Jones, S. Mangiante, M. TuÌĹxen, and F. Weinrank.2017. NEAT: A Platform- and Protocol-Independent Internet Transport API.IEEE Communications Magazine (March 2017). Accepted for publication.[2] libuv team. 2017. libuv — Cross-platform Asynchronous I/O. (2017). https://libuv.org/ Accessed on April 12, 2017.[3] J. Postel. 1980. User Datagram Protocol. RFC 768 (INTERNET STANDARD).(Aug. 1980). http://www.ietf.org/rfc/rfc768.txt[4] J. Postel. 1981. Transmission Control Protocol. RFC 793 (INTERNET STANDARD).(Sept. 1981). http://www.ietf.org/rfc/rfc793.txt Updated by RFCs 1122, 3168, 6093,6528.[5] R. Stewart. 2007. Stream Control Transmission Protocol. RFC 4960 (ProposedStandard). (Sept. 2007). http://www.ietf.org/rfc/rfc4960.txt Updated by RFCs6096, 6335, 7053.

A NEAT Way to do Network Programming

https://aura.abdn.ac.uk/bitstream/2164/10335/1/anrw2017_neatlib.pdf

A NEAT Way to do Network Programming

Abstract

Similar works

Full text

Available Versions

Aberdeen University Research