Agl2017-Socketcan-Print.Pdf

Total Page:16

File Type:pdf, Size:1020Kb

Agl2017-Socketcan-Print.Pdf The CAN Subsystem of the Linux Kernel A Linux CAN driver swiss army knife for automotive use-cases Presentation for Automotive Grade Linux F2F, 201 -0!-0!, "icroc#i$ %&ar'sru#e( SocketCAN – concepts usa!e Controller Area Network simpli#e$ for ner$s ) "edia access *y C+"A,C- ) +tructure of a CAN frame. + - 1 r 3 A 3 C#ecksum CAN-13 3LC 3A?A @ C @ @;F ; ? 3 e %1> 8it( F %11,2= 8it( - @ s %! 8it( %0-6 8yte( L & L % 8it( Ar*itration Contro' Data C#eck Acknowled4e ) +im$'i/ed. 0CAN 1dentifier2 03ata 'en4t#2 03ata 05562 ) Content addressin4 %*y CAN 1denti/er 7 CAN 8us( ) No "AC , Node addresses , A-P , -outin4 9 :ust $'ain ;+1 Layer 2 ) 1ncom$ati*'e <$4rade CAN F3 %1+; 116=6-1.201>(, ex$'ained 'ater Oliver Hartkopp SocketCAN – concepts usa!e Application areas for the Controller Area Network ) 1ndustria' contro' a$$'ications %e545 usin4 t#e CANo$en $rotoco'( ) Food $rocessin4 %e545 on /s# traw'ers( ) Ae#ic'es %Passen4er Cars, ?rucks, Fork 'ifters, etc5( ) -esearc# %e545 Nuc'ear $#ysics( ) +$acecrafts, "arina ) ;i' $'atforms ) Bind ener4y $'ants ) "easurement , +ensors ) +$ecia' @ffects Oliver Hartkopp SocketCAN – concepts usa!e %sa!e of the CAN bus in a vehicle ) +im$le CAN *roadcast messa4es ) Cyclic sent CAN messa4es %for failure detection( ) "u'tip'ex CAN messa4es %containin4 an index for diCerent data $ayload( ) ?rans$ort $rotocols %virtual $oint-to-$oint connection via CAN, e545 1+;-?P: 1+; 1> D>-2( Oliver Hartkopp @very CAN #ardware vendor se'ls #is own driver driver se'ls #is own vendor #ardware @very CAN #ardware #is CAN *und'ed to vendor #ardware CAN a different c#an4e ?#e to a$$lication%E( CAN of t#e ada$tation t#e ur4es Lock-1n Aendor FG SocketCAN – concepts usa!e concepts – SocketCAN ) ) CAN a$$'ication $rotoco's and inte''igent content content inte''igent and a$$'ication $rotoco's CAN inuserspace to*e im$'emented need filters ;n'y one a$$lication can use t#e CAN *us time at a one a$$licationCAN ;n'y canuse t#e mode' driver Linux nostandard CAN was ?#ere ) ) ) ;$eratin4 system CAN driver protoco' application CAN contro''er CAN The former concepts for CAN access CAN for concepts former The Oliver Hartkopp Oliver &)&O &, CAN L)' CAN application *iagnosis &)&O CAN T+ CAN CAN L)' CAN application *iagnosis SocketCAN – concepts usa!e concepts – SocketCAN &)&O T(C 'osch (CNet messa!e mana!ement A$$'ication context ;$eratin4 system &ormer automotive CAN transport protocol implementations transport protocol CAN automotive &ormer Oliver Hartkopp Oliver )$ea- $rotocols inside t#e $rotocols o$eratin4 system context system o$eratin4 1m$'ement CAN transport CAN 1m$'ement ?imeouts for CAN trans$ortt#e in $rotoco's CAN ?imeoutsfor mi''isecondsran4eof can rea'iHed *e are in systems o$eration $rotoco's ?rans$ort ?CP,1P( from known art t#e of %e45?CP +tate ) ) SocketCAN – concepts usa!e concepts – SocketCAN A$$'ication context ;$eratin4 system &, 'osch (CNet CAN T+ CAN )$ea: Meet timin! restictions in the operatin! system context timin! Meet restictions system operatin! in )$ea: the Oliver Hartkopp Oliver SocketCAN – concepts usa!e Concept i$ea from 2//0 %rs says- 1ou are $escribin! 'S* Sockets Oliver Hartkopp SocketCAN – concepts usa!e New protocol family for the Controller Area Net"ork (+&3CAN4 W W B @-"ai' CAN CAN app'ication application Linux +ocket LayerLinux +ocket Layer CAN $rotocol family PFI1N@? PF_CAN 3iCerent CAN *ased $rotoco's ?CP <3P 1C"P -AB 8C" 1+;?P ?P20 ?P16 "CNet K1=J= 1P CAN receive /'ters Packet ProcessingPacket Processing CAN network driver eth0 et#J Oliver Hartkopp SocketCAN – concepts usa!e Implications of usin! network sockets ) @sta*lished socket $ro4rammin4 interface to t#e o$eratin4 system ) Network driver model for networkin4 #ardware %e545 @t#ernet cards) ) Protoco's and routin4 inside t#e o$eratin4 system %e545 for ?CP/1P) ) -andom num*er of instances of network $rotocols ) @xistin4 infrastructure for exam$le for ) efficient messa4e Mueues ) t#e inte4ration of network #ardware drivers Oliver Hartkopp SocketCAN – concepts usa!e The socket pro!rammin! interface example: CAN-over5WLAN Bridge (..) /* some source code – don’t worry */ int can; /* socket handle */ int wlan; struct can_frame mymsg; /* data structure for CA frames */ can ! socket("#_CA $ %&C'_()*A+$ CA _*A,); /* CA *A, %ocket */ wlan ! socket("#_- ./$ %&C'_()*A+$ 0); /* 1("/-" %ocket */ (..) /* set addresses and CA filters */ 2ind(can$ (struct sockaddr *)3can_addr$ si4eof(can_addr)); connect(wlan$ (struct sockaddr *)3in_addr$ si4eof(in_addr)); while (5) 6 read(can$ 3mymsg$ si4eof(struct can_frame)); write(wlan$ 3mymsg$ si4eof(struct can_frame)); 7 Oliver Hartkopp A$$'ication context ;$eratin4 system &)&O &, CAN L)' CAN application *iagnosis SocketCAN – concepts usa!e concepts – SocketCAN &)&O CAN T+ CAN CAN L)' CAN application *iagnosis &)&O T(C 'osch (CNet messa!e mana!ement A$$'ication context ;$eratin4 system Technical improvement with SocketCAN improvement Technical Oliver Hartkopp Oliver ?ransparency and multi-user capabilities multi-user and ?ransparency data structures (eg. struct can_frame( struct (eg. structures data PF_CAN family $rotocol the in incorporated $rotocols (e.g. bitrates) devices network of CAN characteristics %Nraw'( transport without protocols access CAN messages CAN of Filtering Performance ) ) ) ) ) ) ) operating systems %'ike QNX, BSD Unix, Windows) QNX, BSD Unix, %'ike systems operating Generic interface de/nition for the use in other in use the for de/nition interface Generic Definition of CAN specific of Definition users CAN from requirements the -ealizing ) ) ) SocketCAN – concepts usa!e concepts – SocketCAN A$$'ication context ;$eratin4 system The stan$ar$ize$ CAN pro!rammin! interface pro!rammin! CAN The stan$ar$ize$ Oliver Hartkopp Oliver SocketCAN – concepts usa!e Highlights of the protocol family PF3CAN +tandard 8+3 network socket A$p1 A$p2 A$$J $ro4rammin4 interface Linux +ocket Layer -eceive filter lists #andled PFI1N@? PFICAN inside a software interru$t %Linux N@?I-P softirM( -AB 8C" 1+;?P CAN receive /'ters network device driver mode' Packet Processing Network transparency. 'ocal ec#o of sent CAN frames on can0 can3 vcan0 successful transmission Oliver Hartkopp SocketCAN – concepts usa!e 7irtual CAN net"ork $evice driver (vcan4 ) No need for rea' CAN #ardware %availa*le since Linux 25D52>( ) Local echo of sent CAN frames ‘loo$*ack deviceR ) vcan instances can *e created at run-time ) Exam$le. -e$'ay of ve#icle 'o4 files CAN application candump S33 can$'ayer vcan0 55 vcan3 can0 55 canJ vcan0 55 vcan3 Oliver Hartkopp SocketCAN – concepts usa!e How to create a virtual CAN network device ) Loadin4 t#e virtual CAN driver into t#e Linux kerne' sudo mod8ro2e 9can ) Create a virtual CAN interface sudo i8 link add ty8e 9can sudo i8 link add de9 helga ty8e 9can sudo i8 link set 9can0 u8 sudo i8 link set helga u8 Oliver Hartkopp SocketCAN – concepts usa!e CAN network layer protocols an$ CAN frame processin! App1 App2 A$$J cangw Linux +ocket Layer PF_N@?LIN& PFI1N@? PF_CAN CAN GB -AB 8C" 1+;?P CAN receiveCAN /'ters receive /'ters CAN Odisc Packet Processing can0 can3 vcan0 vcan9 Oliver Hartkopp LP-n4 Pen4uin Lo4o *y Arne Geor4 G'editsc# (CC 8T-+A J50) SocketCAN – concepts usa!e CAN38A, – Rea$in! an$ writin! of raw CAN frames A$$1 A$$2 Ap$J can4w ) +imilar to known $ro4rammin4 interfaces Linux Socket Layer PFIN@?L1N& PFI1N@? PFICAN A socket fee's like a $rivate CAN interface CAN GB ) -AB BC" 1+;?P ) $er-socket CAN identifier receive /ltersets CAN receive /'ters CAN Odisc Packet Processin4 ) Linux timestam$s in nano second resolution can0 canJ vcan0 vcan= ) @asy mi4ration of existin4 CAN software ) "ulti$le a$$lications can run inde$endent'y ) Network transparency t#rou4# local echo of sent frames ) Functions can *e s$lit into different $rocesses Oliver Hartkopp SocketCAN – concepts usa!e CAN38A, – Example CAN-over5,LAN Brid!e WLAN-PCCard WLAN-PCCard Bire'ess LAN <3P,1P CAN-PCCard CAN-PCCard CAN CAN Oliver Hartkopp SocketCAN – concepts usa!e CAN38A, – Example CAN-over5,LAN Brid!e (..) /* some source code – don’t worry */ int can; /* socket handle */ int wlan; struct can_frame mymsg; /* data structure for CA frames */ can ! socket("#_CA $ %&C'_()*A+$ CA _*A,); /* CA *A, %ocket */ wlan ! socket("#_- ./$ %&C'_()*A+$ 0); /* 1("/-" %ocket */ (..) /* set addresses and CA filters */ 2ind(can$ (struct sockaddr *)3can_addr$ si4eof(can_addr)); connect(wlan$ (struct sockaddr *)3in_addr$ si4eof(in_addr)); while (5) 6 read(can$ 3mymsg$ si4eof(struct can_frame)); write(wlan$ 3mymsg$ si4eof(struct can_frame)); 7 Oliver Hartkopp htt$s.,,github5com,'inux-can/can-tests SocketCAN – concepts usa!e CAN38A, socket options /* for socket o8tions affecting the socket (not the glo2al system) */ enum 6 CA _*A,_#-:/.* ! 5$ /* set 0 .. n can_filter(s) */ CA _*A,_.**_#-:/.*$ /* set filter for error frames */ CA _*A,_:&&";AC'$ /* local loo82ack (default<on) */ CA _*A,_*.C=_&, _+%)%$ /* recei9e my own msgs (default<off) */ CA _*A,_#(_#*A+.%$ /* allow CA #( frames (default<off) */ CA _*A,_>&- _#-:/.*%$ /* all filters must match to trigger */ 7; /** * A filter matches$ when * * ?recei9ed_can_id@ 3 mask !! can_id 3 mask */ struct can_filter 6 canid_t can_id; canid_t can_mask; 7; htt$s.,,www5kernel5or4,doc,3ocumentation/networking,can.txt Oliver Hartkopp !51.1.1 CAN /'ter usage optimisation SocketCAN – concepts usa!e CAN38A, relate$ can-utils ) candum8 9 display, /lter and lo4 CAN data to /les ) cansend 9 send a sin4le frame ) cangen 9 4enerate %random( CAN traLc ) can8layer 9 re$lay CAN 'o4/les ) can2usload 9 calculate and disp'ay t#e CAN *usload Oliver
Recommended publications
  • Network/Socket Programming in Java
    Network/Socket Programming in Java Rajkumar Buyya Elements of C-S Computing a client, a server, and network Request Client Server Network Result Client machine Server machine java.net n Used to manage: c URL streams c Client/server sockets c Datagrams Part III - Networking ServerSocket(1234) Output/write stream Input/read stream Socket(“128.250.25.158”, 1234) Server_name: “manjira.cs.mu.oz.au” 4 Server side Socket Operations 1. Open Server Socket: ServerSocket server; DataOutputStream os; DataInputStream is; server = new ServerSocket( PORT ); 2. Wait for Client Request: Socket client = server.accept(); 3. Create I/O streams for communicating to clients is = new DataInputStream( client.getInputStream() ); os = new DataOutputStream( client.getOutputStream() ); 4. Perform communication with client Receiive from client: String line = is.readLine(); Send to client: os.writeBytes("Hello\n"); 5. Close sockets: client.close(); For multithreade server: while(true) { i. wait for client requests (step 2 above) ii. create a thread with “client” socket as parameter (the thread creates streams (as in step (3) and does communication as stated in (4). Remove thread once service is provided. } Client side Socket Operations 1. Get connection to server: client = new Socket( server, port_id ); 2. Create I/O streams for communicating to clients is = new DataInputStream( client.getInputStream() ); os = new DataOutputStream( client.getOutputStream() ); 3. Perform communication with client Receiive from client: String line = is.readLine(); Send to client: os.writeBytes("Hello\n");
    [Show full text]
  • Retrofitting Privacy Controls to Stock Android
    Saarland University Faculty of Mathematics and Computer Science Department of Computer Science Retrofitting Privacy Controls to Stock Android Dissertation zur Erlangung des Grades des Doktors der Ingenieurwissenschaften der Fakultät für Mathematik und Informatik der Universität des Saarlandes von Philipp von Styp-Rekowsky Saarbrücken, Dezember 2019 Tag des Kolloquiums: 18. Januar 2021 Dekan: Prof. Dr. Thomas Schuster Prüfungsausschuss: Vorsitzender: Prof. Dr. Thorsten Herfet Berichterstattende: Prof. Dr. Michael Backes Prof. Dr. Andreas Zeller Akademischer Mitarbeiter: Dr. Michael Schilling Zusammenfassung Android ist nicht nur das beliebteste Betriebssystem für mobile Endgeräte, sondern auch ein ein attraktives Ziel für Angreifer. Um diesen zu begegnen, nutzt Androids Sicher- heitskonzept App-Isolation und Zugangskontrolle zu kritischen Systemressourcen. Nutzer haben dabei aber nur wenige Optionen, App-Berechtigungen gemäß ihrer Bedürfnisse einzuschränken, sondern die Entwickler entscheiden über zu gewährende Berechtigungen. Androids Sicherheitsmodell kann zudem nicht durch Dritte angepasst werden, so dass Nutzer zum Schutz ihrer Privatsphäre auf die Gerätehersteller angewiesen sind. Diese Dissertation präsentiert einen Ansatz, Android mit umfassenden Privatsphäreeinstellun- gen nachzurüsten. Dabei geht es konkret um Techniken, die ohne Modifikationen des Betriebssystems oder Zugriff auf Root-Rechte auf regulären Android-Geräten eingesetzt werden können. Der erste Teil dieser Arbeit etabliert Techniken zur Durchsetzung von Sicherheitsrichtlinien
    [Show full text]
  • How to XDP (With Snabb)
    How to XDP (with Snabb) Max Rottenkolber <[email protected]> Tuesday, 21 January 2020 Table of Contents Intro 1 Creating an XDP socket 2 Mapping the descriptor rings 4 Binding an XDP socket to an interface 7 Forwarding packets from a queue to an XDP socket 8 Creating a BPF map . 9 Assembling a BPF program . 9 Attaching a BPF program to an interface . 12 Packet I/O 14 Deallocating the XDP socket 18 Intro Networking in userspace is becoming mainstream. Recent Linux kernels ship with a feature called eXpress Data Path (XDP) that intends to con- solidate kernel-bypass packet processing applications with the kernel’s networking stack. XDP provides a new kind of network socket that al- lows userspace applications to do almost direct I/O with network device drivers while maintaining integration with the kernel’s native network stack. To Snabb XDP looks like just another network I/O device. In fact the XDP ABI/API is so similar to a typical hardware interfaces that it feels a bit like driving a NIC, and not by accident. I think it is fair to describe XDP as a generic interface to Linux network drivers that also 1 has a virtual backend it integrates with: the Linux network stack. In that sense, XDP can be seen as a more hardware centric sibling of AF_PACKET. I can think of two reasons why XDP might be interesting for Snabb users: • While the Snabb community prefers NICs with open hardware interface specifications there are a lot of networking devices out there that lack open specifications.
    [Show full text]
  • Improving Networking
    IMPERIAL COLLEGE LONDON FINALYEARPROJECT JUNE 14, 2010 Improving Networking by moving the network stack to userspace Author: Matthew WHITWORTH Supervisor: Dr. Naranker DULAY 2 Abstract In our modern, networked world the software, protocols and algorithms involved in communication are among some of the most critical parts of an operating system. The core communication software in most modern systems is the network stack, but its basic monolithic design and functioning has remained unchanged for decades. Here we present an adaptable user-space network stack, as an addition to my operating system Whitix. The ideas and concepts presented in this report, however, are applicable to any mainstream operating system. We show how re-imagining the whole architecture of networking in a modern operating system offers numerous benefits for stack-application interactivity, protocol extensibility, and improvements in network throughput and latency. 3 4 Acknowledgements I would like to thank Naranker Dulay for supervising me during the course of this project. His time spent offering constructive feedback about the progress of the project is very much appreciated. I would also like to thank my family and friends for their support, and also anybody who has contributed to Whitix in the past or offered encouragement with the project. 5 6 Contents 1 Introduction 11 1.1 Motivation.................................... 11 1.1.1 Adaptability and interactivity.................... 11 1.1.2 Multiprocessor systems and locking................ 12 1.1.3 Cache performance.......................... 14 1.2 Whitix....................................... 14 1.3 Outline...................................... 15 2 Hardware and the LDL 17 2.1 Architectural overview............................. 17 2.2 Network drivers................................. 18 2.2.1 Driver and device setup.......................
    [Show full text]
  • Post Sockets - a Modern Systems Network API Mihail Yanev (2065983) April 23, 2018
    Post Sockets - A Modern Systems Network API Mihail Yanev (2065983) April 23, 2018 ABSTRACT In addition to providing native solutions for problems, es- The Berkeley Sockets API has been the de-facto standard tablishing optimal connection with a Remote point or struc- systems API for networking. However, designed more than tured data communication, we have identified that a com- three decades ago, it is not a good match for the networking mon issue with many of the previously provided networking applications today. We have identified three different sets of solutions has been leaving the products vulnerable to code problems in the Sockets API. In this paper, we present an injections and/or buffer overflow attacks. The root cause implementation of Post Sockets - a modern API, proposed by for such problems has mostly proved to be poor memory Trammell et al. that solves the identified limitations. This or resource management. For this reason, we have decided paper can be used for basis of evaluation of the maturity of to use the Rust programming language to implement the Post Sockets and if successful to promote its introduction as new API. Rust is a programming language, that provides a replacement API to Berkeley Sockets. data integrity and memory safety guarantees. It uses region based memory, freeing the programmer from the responsibil- ity of manually managing the heap resources. This in turn 1. INTRODUCTION eliminates the possibility of leaving the code vulnerable to Over the years, writing networked applications has be- resource management errors, as this is handled by the lan- come increasingly difficult.
    [Show full text]
  • Lesson-3 Case Study of Coding for Sending Application Layer Byte Streams on a TCP/IP Network Router Using RTOS Vxworks
    Design Examples and Case Studies of Program Modeling and Programming with RTOS: Lesson-3 Case Study Of Coding For Sending Application Layer Byte Streams on a TCP/IP Network Router Using RTOS VxWorks Chapter-13 L03: "Embedded Systems - Architecture, Programming and Design" , 2015 1 Raj Kamal, Publs.: McGraw-Hill Education 1. Specifications Chapter-13 L03: "Embedded Systems - Architecture, Programming and Design" , 2015 2 Raj Kamal, Publs.: McGraw-Hill Education TCP/IP Stack In TCP/IP suite of protocols, application layer transfers the data with appropriate header words to transport layer. At transport layer, either UDP or TCP protocol is used and additional header words placed. Chapter-13 L03: "Embedded Systems - Architecture, Programming and Design" , 2015 3 Raj Kamal, Publs.: McGraw-Hill Education TCP/IP Stack transmitting subsystem Chapter-13 L03: "Embedded Systems - Architecture, Programming and Design" , 2015 4 Raj Kamal, Publs.: McGraw-Hill Education TCP/IP Stack UDP is connection-less protocol for datagram transfer of total size including headers of less than 216 Byte. TCP is connection oriented protocol, in which data of unlimited size can be transferred in multiple sequences to the internet layer At internet layer, the IP protocol is used and IP packets are formed, each packet with an IP header transfers to the network through network driver subsystem. Chapter-13 L03: "Embedded Systems - Architecture, Programming and Design" , 2015 5 Raj Kamal, Publs.: McGraw-Hill Education TCP/IP stack A TCP/IP stack network driver is available in the RTOSes It has a library, sockLib for socket programming. The reader may refer to VxWorks Programmer’s Guide when using these APIs and sockLib.
    [Show full text]
  • Learning Python Network Programming
    Learning Python Network Programming Utilize Python 3 to get network applications up and running quickly and easily Dr. M. O. Faruque Sarker Sam Washington BIRMINGHAM - MUMBAI Learning Python Network Programming Copyright © 2015 Packt Publishing All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews. Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book. Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information. First published: June 2015 Production reference: 1100615 Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK. ISBN 978-1-78439-600-8 www.packtpub.com Credits Authors Project Coordinator Dr. M. O. Faruque Sarker Izzat Contractor Sam Washington Proofreaders Reviewers Stephen Copestake Konstantin Manchev Manchev Safis Editing Vishrut Mehta Anhad Jai Singh Indexer Hemangini Bari Ben Tasker Ilja Zegars Graphics Abhinash Sahu Commissioning Editor Kunal Parikh Production Coordinator Shantanu Zagade Acquisition Editor Kevin Colaco Cover Work Shantanu Zagade Content Development Editor Rohit Singh Technical Editor Saurabh Malhotra Copy Editors Ameesha Green Rashmi Sawant Trishla Singh About the Authors Dr.
    [Show full text]
  • Towards Access Control for Isolated Applications
    Towards Access Control for Isolated Applications Kirill Belyaev and Indrakshi Ray Computer Science Department, Colorado State University, Fort Collins, U.S.A Keywords: Access Control, Service and Systems Design, Inter-application Communication. Abstract: With the advancements in contemporary multi-core CPU architectures, it is now possible for a server operating system (OS), such as Linux, to handle a large number of concurrent application services on a single server instance. Individual application components of such services may run in different isolated runtime environ- ments, such as chrooted jails or application containers, and may need access to system resources and the ability to collaborate and coordinate with each other in a regulated and secure manner. We propose an access control framework for policy formulation, management, and enforcement that allows access to OS resources and also permits controlled collaboration and coordination for service components running in disjoint containerized environments under a single Linux OS server instance. The framework consists of two models and the policy formulation is based on the concept of policy classes for ease of administration and enforcement. The policy classes are managed and enforced through a Linux Policy Machine (LPM) that acts as the centralized reference monitor and provides a uniform interface for accessing system resources and requesting application data and control objects. We present the details of our framework and also discuss the preliminary implementation to demonstrate the feasibility of our approach. 1 INTRODUCTION plications for controlling access to OS resources, for regulating the access requests to the application data The advancements in contemporary multi-core CPU and control objects used for inter-application commu- architectures have greatly improved the ability of nication between service components.
    [Show full text]
  • COS 318: Operating Systems Message Passing
    Motivation u Locks, semaphores, monitors are good but they only COS 318: Operating Systems work under the shared-address-space model l Threads in the same process l Processes that share an address space Message Passing u We have assumed that processes/threads communicate via shared data (counter, producer-consumer buffer, …) u How to synchronize and communicate among processes with different address spaces? (http://www.cs.princeton.edu/courses/cos318/) l Inter-process communication (IPC) u Can we have a single set of primitives that work for all cases: single machine OS, multiple machines same OS, multiple machines multiple OS, distributed? With No Shared Address Space Sending A Message u No need for explicit mutual exclusion primitives l Processes cannot touch the same data directly Within A Computer Across A Network u Communicate by sending and receiving explicit messages: Message Passing P1 P2 Send() Recv() u Synchronization is implicit in message passing Send() Recv() l No need for explicit mutual exclusion Network l Event ordering via sending and receiving of messages OS Kernel OS OS u More portable to different environments, though lacks COS461 some of the convenience of a shared address space u Typically, communication in consummated via a send P1 can send to P2, P2 can send to P1 and a matching receive 4 1 Simple Send and Receive Simple API send( dest, data ), receive( src, data ) send( dest, data ), receive( src, data ) S S R u Destination or source l Direct address: send(dest, data) node Id, process Id recv(src, data) l Indirect address: send(dest, data) mailbox, socket, R channel, … u Data l Buffer (addr) and size recv(src, data) u Send “data” specifies where the data are in sender’s address space l Anything else that u Recv “data” specifies where the incoming message data should be specifies the source put in receiver’s address space data or destination data structure 5 6 Simple Semantics Issues/options u Send call does not return until data have been copied u Asynchronous vs.
    [Show full text]
  • ARTICLE VII: UNBUNDLED NETWORK ELEMENTS Centurytel/Socket Page 18 Of45 FINAL CONFORMING
    ARTICLE VII : UNBUNDLED NETWORK ELEMENTS CenturyTel/Socket Page 14 of 45 FINAL CONFORMING Section 2.20.7 through Section 2.20 .7 .4. For purposes of calculating and applying an "annual basis," it means a consecutive 12-month period, beginning upon CenturyTel's written notice that an audit will be performed for the State. 2 .20 .7.1 [Intentionally omitted] 2 .20 .7.2 Unless otherwise agreed by the Parties (including at the time of the audit), the independent auditor shall perform its evaluation in accordance with the standards established by the American Institute for Certified Public Accountants (AICPA), which will require the auditor to perform an "examination engagement" and issue an opinion that includes the auditor's determination regarding Socket's compliance with the qualifying service Eligibility Requirements criteria. The independent auditor's report will conclude whether Socket complied in all material respects with this Section 2.20. 2 .20 .7.3 Consistent with standard auditing practices, such audits require compliance testing designed by the independent auditor, which typically include an examination of a sample selected in accordance with the independent auditor's judgment. 2.20 .7.4 Should the independent auditor's report conclude that Socket failed to comply in all material respects with Section 2.20, Socket must true-up any difference in payments paid to CenturyTel and the rates and charges Socket would have owed CenturyTel beginning from the date that the non-compliant circuit was established as a UNE/UNE combination, in whole or in part (notwithstanding any other provision hereof), but no earlier than the date on which this Section 2.20 of this Article is effective .
    [Show full text]
  • Network Programming Management
    IT2351 NETWORK PROGRAMMING AND MANAGEMENT A Course Material on Network Programming Management By Mrs.D.KalaiAbirami ASSISTANT PROFESSOR DEPARTMENT OF INFORMATION TECHNOLOGY SASURIE COLLEGE OF ENGINEERING VIJAYAMANGALAM – 638 056 SCE Department Of Information Technology & Computer Applications IT2351 NETWORK PROGRAMMING AND MANAGEMENT QUALITY CERTIFICATE This is to certify that the e-course material Subject Code : IT2351 Subject : Network Programming and Management Class : III B.tech(INFORMATION TECHNOLOGY) being prepared by me and it meets the knowledge requirement of the university curriculum. Signature of the Author Name: D.Kalai Abirami Designation: AP This is to certify that the course material being prepared by Mrs.D.Kalai Abirami is of adequate quality. She has referred more than five books among them minimum one is from abroad author. Signature of HD Name: S.ASHOK KUMAR SEAL SCE Department Of Information Technology & Computer Applications IT2351 NETWORK PROGRAMMING AND MANAGEMENT IT2351 – NETWORK PROGRAMMING AND MANAGEMENT UNIT I ELEMENTARY TCP SOCKETS Introduction to socket programming – Overview of TCP / IP protocols – Introduction to sockets – Socket address structures – Byte ordering functions – Address conversion functions – Elementary TCP sockets – Socket – Connect – Bind – Listen – Accept – Read – Write – Close functions – Iterative server – Concurrent server. UNIT II APPLICATION DEVELOPMENT TCP echo server – TCP echo client – POSIX signal handling – Server with multiple clients – Boundary conditions– Server process crashes–
    [Show full text]
  • Host-Side Drivers User Guide for Linux Release 3.1.0
    Host-Side Drivers User Guide for Linux Release 3.1.0 Part Number: 10-00125-02-A0 Copyright © 2005 Topspin Communications, Inc. All rights reserved. The Topspin Switched Computing System, Topspin Host Channel Adapter, Topspin Element Manager, and collateral software programs and documentation are subject to and made available only pursuant to the license agreement signed by you and Topspin, Communications, Inc. (or if no signed license agreement exists, the license agreement included with your original media) and may only be used in accordance with the terms of that agreement. Making copies, modifications, or compilation works of the software except as specifically allowed in that agreement is prohibited by law and constitutes a punishable violation of the law. This documentation may not be copied, modified or reduced to any electronic or machine-readable form without Topspin Communication, Inc.'s prior written consent. As defined in FAR section 2.101, DFAR section 252.227-7014(a)(1) and DFAR section 252.227-7014(a)(5) or otherwise, the collateral software programs provided to you are “commercial items,” “commercial computer software” and/or “commercial computer software documentation.” Consistent with DFAR section 227.7202, FAR section 12.212 and other sections, any use, modification, reproduction, release, performance, display, disclosure or distribution thereof by or for the U.S. Government shall be governed solely by the terms of the license agreement and shall be prohibited except to the extent expressly permitted by the terms of that agreement. Any technical data provided that is not covered by the above provisions shall be deemed “technical data-commercial items” pursuant to DFAR section 227.7015(a) or equivalent.
    [Show full text]