Enviar búsqueda
Cargar
Prog ii
•
0 recomendaciones
•
418 vistas
Sanchit Patil
Seguir
Tecnología
Denunciar
Compartir
Denunciar
Compartir
1 de 71
Descargar ahora
Descargar para leer sin conexión
Recomendados
Unit 7
Unit 7
siddr
Unix system programming
Unix system programming
Syed Mustafa
Linux directory structure by jitu mistry
Linux directory structure by jitu mistry
JITU MISTRY
4.6 create and change hard and symbolic links v2
4.6 create and change hard and symbolic links v2
Acácio Oliveira
Introduction to Unix-like systems (Part I-IV)
Introduction to Unix-like systems (Part I-IV)
hildenjohannes
Linux file system
Linux file system
Midaga Mengistu
File System Hierarchy
File System Hierarchy
sritolia
Files and directories in Linux 6
Files and directories in Linux 6
Meenakshi Paul
Recomendados
Unit 7
Unit 7
siddr
Unix system programming
Unix system programming
Syed Mustafa
Linux directory structure by jitu mistry
Linux directory structure by jitu mistry
JITU MISTRY
4.6 create and change hard and symbolic links v2
4.6 create and change hard and symbolic links v2
Acácio Oliveira
Introduction to Unix-like systems (Part I-IV)
Introduction to Unix-like systems (Part I-IV)
hildenjohannes
Linux file system
Linux file system
Midaga Mengistu
File System Hierarchy
File System Hierarchy
sritolia
Files and directories in Linux 6
Files and directories in Linux 6
Meenakshi Paul
Linux 系統程式--第一章 i/o 函式
Linux 系統程式--第一章 i/o 函式
艾鍗科技
Unix file systems 2 in unix internal systems
Unix file systems 2 in unix internal systems
senthilamul
Lamp
Lamp
Reka
Linux Directory Structure
Linux Directory Structure
Kevin OBrien
Jaime Peñalba - Kernel exploitation. ¿El octavo arte? [rooted2019]
Jaime Peñalba - Kernel exploitation. ¿El octavo arte? [rooted2019]
RootedCON
Den-long-men of void-jar(hardware and Software)
Den-long-men of void-jar(hardware and Software)
HU-man
Operating system lab manual
Operating system lab manual
Meerut Institute of Technology
Disk forensics
Disk forensics
Chiawei Wang
Unix files
Unix files
Sunil Rm
Part 03 File System Implementation in Linux
Part 03 File System Implementation in Linux
Tushar B Kute
Unix Command Line Productivity Tips
Unix Command Line Productivity Tips
Keith Bennett
Ntfs forensics
Ntfs forensics
n|u - The Open Security Community
Linux file system nevigation
Linux file system nevigation
hetaldobariya
Basic Unix
Basic Unix
Rajesh Kumar
Unix training session 1
Unix training session 1
Anil Kumar Kapil,PMP®
www.indonezia.net Hacking Windows Registry
www.indonezia.net Hacking Windows Registry
Chandra Pr. Singh
De-Anonymizing Live CDs through Physical Memory Analysis
De-Anonymizing Live CDs through Physical Memory Analysis
Andrew Case
Nguyễn Vũ Hưng: Basic Linux Power Tools
Nguyễn Vũ Hưng: Basic Linux Power Tools
Vu Hung Nguyen
Lesson 2 Understanding Linux File System
Lesson 2 Understanding Linux File System
Sadia Bashir
Unit 6
Unit 6
siddr
Unit 5
Unit 5
siddr
Usp notes unit6-8
Usp notes unit6-8
Syed Mustafa
Más contenido relacionado
La actualidad más candente
Linux 系統程式--第一章 i/o 函式
Linux 系統程式--第一章 i/o 函式
艾鍗科技
Unix file systems 2 in unix internal systems
Unix file systems 2 in unix internal systems
senthilamul
Lamp
Lamp
Reka
Linux Directory Structure
Linux Directory Structure
Kevin OBrien
Jaime Peñalba - Kernel exploitation. ¿El octavo arte? [rooted2019]
Jaime Peñalba - Kernel exploitation. ¿El octavo arte? [rooted2019]
RootedCON
Den-long-men of void-jar(hardware and Software)
Den-long-men of void-jar(hardware and Software)
HU-man
Operating system lab manual
Operating system lab manual
Meerut Institute of Technology
Disk forensics
Disk forensics
Chiawei Wang
Unix files
Unix files
Sunil Rm
Part 03 File System Implementation in Linux
Part 03 File System Implementation in Linux
Tushar B Kute
Unix Command Line Productivity Tips
Unix Command Line Productivity Tips
Keith Bennett
Ntfs forensics
Ntfs forensics
n|u - The Open Security Community
Linux file system nevigation
Linux file system nevigation
hetaldobariya
Basic Unix
Basic Unix
Rajesh Kumar
Unix training session 1
Unix training session 1
Anil Kumar Kapil,PMP®
www.indonezia.net Hacking Windows Registry
www.indonezia.net Hacking Windows Registry
Chandra Pr. Singh
De-Anonymizing Live CDs through Physical Memory Analysis
De-Anonymizing Live CDs through Physical Memory Analysis
Andrew Case
Nguyễn Vũ Hưng: Basic Linux Power Tools
Nguyễn Vũ Hưng: Basic Linux Power Tools
Vu Hung Nguyen
Lesson 2 Understanding Linux File System
Lesson 2 Understanding Linux File System
Sadia Bashir
La actualidad más candente
(19)
Linux 系統程式--第一章 i/o 函式
Linux 系統程式--第一章 i/o 函式
Unix file systems 2 in unix internal systems
Unix file systems 2 in unix internal systems
Lamp
Lamp
Linux Directory Structure
Linux Directory Structure
Jaime Peñalba - Kernel exploitation. ¿El octavo arte? [rooted2019]
Jaime Peñalba - Kernel exploitation. ¿El octavo arte? [rooted2019]
Den-long-men of void-jar(hardware and Software)
Den-long-men of void-jar(hardware and Software)
Operating system lab manual
Operating system lab manual
Disk forensics
Disk forensics
Unix files
Unix files
Part 03 File System Implementation in Linux
Part 03 File System Implementation in Linux
Unix Command Line Productivity Tips
Unix Command Line Productivity Tips
Ntfs forensics
Ntfs forensics
Linux file system nevigation
Linux file system nevigation
Basic Unix
Basic Unix
Unix training session 1
Unix training session 1
www.indonezia.net Hacking Windows Registry
www.indonezia.net Hacking Windows Registry
De-Anonymizing Live CDs through Physical Memory Analysis
De-Anonymizing Live CDs through Physical Memory Analysis
Nguyễn Vũ Hưng: Basic Linux Power Tools
Nguyễn Vũ Hưng: Basic Linux Power Tools
Lesson 2 Understanding Linux File System
Lesson 2 Understanding Linux File System
Destacado
Unit 6
Unit 6
siddr
Unit 5
Unit 5
siddr
Usp notes unit6-8
Usp notes unit6-8
Syed Mustafa
Unit 2
Unit 2
siddr
Unit 1
Unit 1
siddr
Unit 4
Unit 4
siddr
Unit 3
Unit 3
siddr
Unix operating system
Unix operating system
ABhay Panchal
Destacado
(8)
Unit 6
Unit 6
Unit 5
Unit 5
Usp notes unit6-8
Usp notes unit6-8
Unit 2
Unit 2
Unit 1
Unit 1
Unit 4
Unit 4
Unit 3
Unit 3
Unix operating system
Unix operating system
Similar a Prog ii
Prog i
Prog i
Sanchit Patil
Lamp1
Lamp1
Nadhi ya
Lamp1
Lamp1
Reka
Unix Administration
Unix Administration
Nishant Munjal
beginner.en.print
beginner.en.print
aniruddh Tyagi
beginner.en.print
beginner.en.print
aniruddh Tyagi
beginner.en.print
beginner.en.print
Aniruddh Tyagi
Linux training
Linux training
Parker Fong
Tutorial 2
Tutorial 2
tech2click
Linux introduction (eng)
Linux introduction (eng)
Anatoliy Okhotnikov
Linux Commands
Linux Commands
Ramasubbu .P
Unix_commands_theory
Unix_commands_theory
Niti Patel
Linux
Linux
SINGH PROJECTS
Linux Shell Basics
Linux Shell Basics
Constantine Nosovsky
Security coding c and c++ ch8 (1)
Security coding c and c++ ch8 (1)
Chia-Hao Tsai
Unix
Unix
Sudharsan S
Linux Introduction (Commands)
Linux Introduction (Commands)
anandvaidya
Linux introduction-commands2338
Linux introduction-commands2338
Cam YP Co., Ltd
Linux introduction-commands2338
Linux introduction-commands2338
Cam YP Co., Ltd
Unix
Unix
Thesis Scientist Private Limited
Similar a Prog ii
(20)
Prog i
Prog i
Lamp1
Lamp1
Lamp1
Lamp1
Unix Administration
Unix Administration
beginner.en.print
beginner.en.print
beginner.en.print
beginner.en.print
beginner.en.print
beginner.en.print
Linux training
Linux training
Tutorial 2
Tutorial 2
Linux introduction (eng)
Linux introduction (eng)
Linux Commands
Linux Commands
Unix_commands_theory
Unix_commands_theory
Linux
Linux
Linux Shell Basics
Linux Shell Basics
Security coding c and c++ ch8 (1)
Security coding c and c++ ch8 (1)
Unix
Unix
Linux Introduction (Commands)
Linux Introduction (Commands)
Linux introduction-commands2338
Linux introduction-commands2338
Linux introduction-commands2338
Linux introduction-commands2338
Unix
Unix
Último
Powerpoint exploring the locations used in television show Time Clash
Powerpoint exploring the locations used in television show Time Clash
charlottematthew16
Tampa BSides - Chef's Tour of Microsoft Security Adoption Framework (SAF)
Tampa BSides - Chef's Tour of Microsoft Security Adoption Framework (SAF)
Mark Simos
DMCC Future of Trade Web3 - Special Edition
DMCC Future of Trade Web3 - Special Edition
Dubai Multi Commodity Centre
AI as an Interface for Commercial Buildings
AI as an Interface for Commercial Buildings
Memoori
SIP trunking in Janus @ Kamailio World 2024
SIP trunking in Janus @ Kamailio World 2024
Lorenzo Miniero
The Future of Software Development - Devin AI Innovative Approach.pdf
The Future of Software Development - Devin AI Innovative Approach.pdf
SeasiaInfotech2
Install Stable Diffusion in windows machine
Install Stable Diffusion in windows machine
Padma Pradeep
Ensuring Technical Readiness For Copilot in Microsoft 365
Ensuring Technical Readiness For Copilot in Microsoft 365
2toLead Limited
Leverage Zilliz Serverless - Up to 50X Saving for Your Vector Storage Cost
Leverage Zilliz Serverless - Up to 50X Saving for Your Vector Storage Cost
Zilliz
"Federated learning: out of reach no matter how close",Oleksandr Lapshyn
"Federated learning: out of reach no matter how close",Oleksandr Lapshyn
Fwdays
My Hashitalk Indonesia April 2024 Presentation
My Hashitalk Indonesia April 2024 Presentation
Ridwan Fadjar
"Debugging python applications inside k8s environment", Andrii Soldatenko
"Debugging python applications inside k8s environment", Andrii Soldatenko
Fwdays
Designing IA for AI - Information Architecture Conference 2024
Designing IA for AI - Information Architecture Conference 2024
Enterprise Knowledge
Streamlining Python Development: A Guide to a Modern Project Setup
Streamlining Python Development: A Guide to a Modern Project Setup
Florian Wilhelm
"LLMs for Python Engineers: Advanced Data Analysis and Semantic Kernel",Oleks...
"LLMs for Python Engineers: Advanced Data Analysis and Semantic Kernel",Oleks...
Fwdays
Advanced Test Driven-Development @ php[tek] 2024
Advanced Test Driven-Development @ php[tek] 2024
Scott Keck-Warren
DevoxxFR 2024 Reproducible Builds with Apache Maven
DevoxxFR 2024 Reproducible Builds with Apache Maven
Hervé Boutemy
Search Engine Optimization SEO PDF for 2024.pdf
Search Engine Optimization SEO PDF for 2024.pdf
RankYa
Artificial intelligence in cctv survelliance.pptx
Artificial intelligence in cctv survelliance.pptx
hariprasad279825
Dev Dives: Streamline document processing with UiPath Studio Web
Dev Dives: Streamline document processing with UiPath Studio Web
UiPathCommunity
Último
(20)
Powerpoint exploring the locations used in television show Time Clash
Powerpoint exploring the locations used in television show Time Clash
Tampa BSides - Chef's Tour of Microsoft Security Adoption Framework (SAF)
Tampa BSides - Chef's Tour of Microsoft Security Adoption Framework (SAF)
DMCC Future of Trade Web3 - Special Edition
DMCC Future of Trade Web3 - Special Edition
AI as an Interface for Commercial Buildings
AI as an Interface for Commercial Buildings
SIP trunking in Janus @ Kamailio World 2024
SIP trunking in Janus @ Kamailio World 2024
The Future of Software Development - Devin AI Innovative Approach.pdf
The Future of Software Development - Devin AI Innovative Approach.pdf
Install Stable Diffusion in windows machine
Install Stable Diffusion in windows machine
Ensuring Technical Readiness For Copilot in Microsoft 365
Ensuring Technical Readiness For Copilot in Microsoft 365
Leverage Zilliz Serverless - Up to 50X Saving for Your Vector Storage Cost
Leverage Zilliz Serverless - Up to 50X Saving for Your Vector Storage Cost
"Federated learning: out of reach no matter how close",Oleksandr Lapshyn
"Federated learning: out of reach no matter how close",Oleksandr Lapshyn
My Hashitalk Indonesia April 2024 Presentation
My Hashitalk Indonesia April 2024 Presentation
"Debugging python applications inside k8s environment", Andrii Soldatenko
"Debugging python applications inside k8s environment", Andrii Soldatenko
Designing IA for AI - Information Architecture Conference 2024
Designing IA for AI - Information Architecture Conference 2024
Streamlining Python Development: A Guide to a Modern Project Setup
Streamlining Python Development: A Guide to a Modern Project Setup
"LLMs for Python Engineers: Advanced Data Analysis and Semantic Kernel",Oleks...
"LLMs for Python Engineers: Advanced Data Analysis and Semantic Kernel",Oleks...
Advanced Test Driven-Development @ php[tek] 2024
Advanced Test Driven-Development @ php[tek] 2024
DevoxxFR 2024 Reproducible Builds with Apache Maven
DevoxxFR 2024 Reproducible Builds with Apache Maven
Search Engine Optimization SEO PDF for 2024.pdf
Search Engine Optimization SEO PDF for 2024.pdf
Artificial intelligence in cctv survelliance.pptx
Artificial intelligence in cctv survelliance.pptx
Dev Dives: Streamline document processing with UiPath Studio Web
Dev Dives: Streamline document processing with UiPath Studio Web
Prog ii
1.
UNIX Systems Programming
II Short Course Notes Alan Dix © 1996 http://www.hcibook.com/alan/ UNIXSystems Programming II UNIXSystems Programming II UNIXSystems Programming II UNIXSystems Programming II UNIXSystems Programming II
2.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/i UNIXSystems Programming II Course Outline Alan Dix http://www.hcibook.com/alan/ Session 1 files and devices inodes, stat, /dev files, ioctl, reading directories, file descriptor sharing and dup2, locking and network caching Session 2 process handling UNIX processes, fork, exec, process death: SIGCHLD and wait, kill and I/O issues for fork Session 3 inter-process communication pipes: at the shell , in C code and use with exec, pseudo-terminals, sockets and deadlock avoidance Session 4 non-blocking I/O and select UNIX events: signals, times and I/O; setting timers, polling, select, interaction with signals and an example Internet server
3.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/ii UNIXSystems Programming II Reading ¥ The Unix V Environment, Stephen R. Bourne, Wiley, 1987, ISBN 0 201 18484 2 The author of the Borne Shell! A 'classic' which deals with system calls, the shell and other aspects of UNIX. ¥ Unix For Programmers and Users, Graham Glass, Prentice-Hall, 1993, ISBN 0 13 061771 7 Slightly more recent book also covering shell and C programming. Ì BEWARE Ð UNIX systems differ in details, check on-line documentation ¥ UNIX manual pages: man creat etc. Most of the system calls and functions are in section 2 and 3 of the manual. The pages are useful once you get used to reading them! ¥ The include files themselves /usr/include/time.h etc. Takes even more getting used to, but the ultimate reference to structures and definitions on your system.
4.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/1 UNIXSystems Programming II Session 1 files and devices ¥ inodes ¥ stat ¥ /dev ¥ special devices ¥ ioctl, fnctl ¥ directories ¥ file descriptors and dup2 ¥ locking and network problems a simple ls
5.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/2 UNIX filesystem UNIX filesystem: r disk (partition) Ð inode table (file contents) r directories Ð maps names to files r mount points Ð links between disks r special files Ð e.g. /dev, /n 0 1 2 579 580 581 582 ... ... tom fred .. . 2 580 0 582 directory hd2
6.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/3 inodes ¥ each disk has an inode table r one inode for each file on the disk ¥ inode contains r permissions: read/write/execute r other flags: directory, symbolic link, setuid r times: creation, modification, access r pointers to disk blocks containing file ¥ directories r of the form: filename → inode number r no other information Ð all in the inode ¥ hard link: r two names → same inode number r when safe to delete?
7.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/4 inode reference counts ¥ inode has count of number of links ¥ unlink system call does two things: x remove directory entry y subtract 1 from link count ¥ when count is zero safe to delete file . . . or is it? $ what about open files? r file disappears r program does read/write r disaster UNIX also keeps in-memory reference count r only deleted when both are zero r last close to the file → file finally disappears
8.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/5 stat system call #include sys/types.h #include sys/stat.h struct stat buf int res = stat(filename,buf ); ¥ gets information for the file pointed to by filename ¥ all the inode information ¥ in addition device information r device number (which disk) r inode number ¥ inode information includes: r mode Ð buf.st_mode r size Ð buf.st_size r owner Ð buf.st_uid r block size Ð buf.st_blksize r number of links Ð buf.st_nlink r update time Ð buf.st_mtime ¥ can also get/set mode using chmod
9.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/6 stat – 2 ¥ variants of stat: lstat(filename,buf) r same except for symbolic links r gives info for link rather than target fstat(fd,buf) r gives info for open file descriptor r useful for standard input/output ¥ mode flags Ð buf.st_mode r permissions r file type ¥ can test mode flags using bit operations if (buf.st_mode S_IWUSR ) ... Ð user has write permission? ¥ also macros for file types, including: S_ISDIR(buf.st_mode) Ð directory S_ISREG(buf.st_mode) Ð regular file S_ISLNK(buf.st_mode) Ð symbolic link
10.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/7 /dev ¥ UNIX makes everything look like a file! ¥ many physical devices appear in /dev r /dev/hd?? Ð hard disk r /dev/fd?? Ð floppy disk r /dev/s?? Ð serial port ¥ in addition, many logical devices r /dev/tty Ð the terminal for this process r /dev/win?? Ð windows r /dev/pty?? /dev/tty?? Ð pseudo-terminals r /dev/kmem Ð kernel memory r /dev/null Ð empty source, infinite sink ¥ logical devices may be system wide e.g. pseudo-terminals ¥ or different for each process e.g. /dev/tty
11.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/8 special files/devices ¥ logical and physical devices of two kinds: r character special r block special ¥ character special files r when it is reasonable to think of the device as a sequence of bytes e.g. serial port ¥ block special files r when it is reasonable to think of the device as a sequence of blocks of bytes e.g. formatted disk r get the block size right! ¥ some physical devices have both r hard disk high level Ð block special low level Ð character special r different semantics
12.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/9 ioctl system call ¥ all devices appear as files . . . . . . equal but different ! ¥ ioctl system call allows device specific control int res = ioctl(fd, cmd, arg ); int fd Ð file descriptor to control int cmd Ð command/request to perform caddr_t arg; Ð data structure to use/fill ¥ nature of requests depend on device r see section 4 of manual for device specific requests filio Ð general ÔfileÕ requests termio - terminal requests sockio - socket requests (e.g. TCP/IP) ¥ type of argument depends on request r read description of request in manual page ¥ argument may supply data and/or be used for result ¥ some device specific wrapper functions: stty/gtty Ð terminal drivers fcntl Ð ÔfilesÕ (not just disk)
13.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/10 ioctl – examples ¥ close on exec #include sys/filio.h ioctl(fd,FIOCLEX,NULL); ¥ donÕt block on read/write #include sys/filio.h int flag = 1; ioctl(fd,FIONBIO,flag); ¥ get terminal window size e.g. under X when windows may resize #include sys/termios.h struct winsize wsz; ioctl(fd,TIOCGWINSZ,wsz);
14.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/11 fcntl system call #include sys/filio.h #include unistd.h #include fcntl.h int res = fcntl(fd, cmd, arg ); int fd Ð file descriptor to control int cmd Ð command/request to perform int arg; Ð argument purports to be an int but is often a pointer! ¥ performs operations on open file descriptors ¥ similar to ioctl, with some overlap ¥ some requests cause ioctl to be called ¥ others cannot be performed with ioctl (e.g. locks) ¥ N.B. argument purports to be an int . . . . . . but is often a pointer!
15.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/12 directories ¥ stored as ordinary file r sequence of bytes ¥ inode entry says it is a directory ¥ can be accessed using ordinary read $ only if you know the format!! ⇒ special library functions r read the directory r put it in a data structure
16.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/13 reading directories #include dirent.h opendir, readdir, closdir, seekdir, telldir, rewinddir ¥ thedirectory functions in man(3) r like a stdio for directories r functions to open, read, and close r but not write - that is creat! r also ÔseekÕ and ÔtellÕ style functions ¥ data structures r DIR structure takes the place of FILE* r read returns a pointer to a struct dirent r only important field is d_name Ð the file name #include dirent.h struct dirent *dp; DIR *dirp = opendir(testdir); dp = readdir(dirp); while ( dp != NULL ) { printf(%sn,dp-d_name); dp = readdir(dirp); } closedir(dirp);
17.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/14 shared file descriptors ¥ file descriptors r point to shared structures ¥ shared: x within a process y between processes ¥ arises from: x dup2/dup2 system calls y fork system call ¥ shared means r same file pointer writes Ð sequenced reads Ð first come / first served r last close matters files Ð may be deleted network Ð connection broken
18.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/15 dup2 system call int res = dup2(old_fd, new_fd); ¥ makes new_fd point to same file/stream as old_fd ¥ new_fd is closed if already open ¥ most often used with standard I/O descriptors: dup2(fd,0); Ð standard input reads from fd ¥ can close the old descriptor . . . but new descriptor still works dup2(fd,0); close(fd): n = read(0,buff,buff_len); ¥ negative return on failure
19.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/16 locks ¥ lots of processes accessing the same file ⇒ trouble! ¥ locks prevent multiple access r atomic Ð cannot have half a lock r mutual exclusion Ð at most one process has the lock ¥ traditional UNIX lock file: r use creat to make an unreadable file creat(lockfile,0); r subsequent calls to creat will fail (because creat on an existing file acts as an open) r when done use creat to delete lock file uses ordinary UNIX file handling Ð no special locking mechanism needed $ fails with network file systems
20.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/17 network files – NFS ¥ files stored on one or more servers ¥ remote files accessed by sending network messages ¥ simply sendUNIX open/read/write requests? $ too much network traffic $ too much server state ¥ NFS: client workstations cache files server is stateless (⇒ no open) ¥ some files donÕt last long ⇒ donÕt tell server about every creat/write periodic synchronisation ¥ some files donÕt last long ⇒ donÕt tell server about every creat/write periodic synchronisation $ creat only mutually exclusive on each machine $ odd anomalies with read/write
21.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/18 flock and the lock daemon #include sys/file.h int res = flock(fd,op); int fd Ð an open file descriptor int op Ð a locking operation ¥ locking operation one of: LOCK_SH Ð shared lock (mainly for read) LOCK_EX Ð exclusive lock (mainly for write) LOCK_UN Ð release lock (unlock) ¥ if file is already locked r normally flock blocks until it is free r can or operation with LOCK_NB ⇒ never blocks Ð error return instead ¥ how does it work r background process lockd on each machine r they handle the shared state only have shared state when necessary $ still insecure Ð locks are advisory r process can ignore it and open a locked file
22.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/19 Hands on copy the code fragment on the directory slide to write a Ômini-lsÕ program it should list the file pointed to by its program first argument (argv[1]) compile and run it now modify it to use stat on each file get it to add a slash Õ/Õ to the end of directories use your imagination to add other status info! compile and run again if you have time, try adding a Ô-LÕ option when the Ô-LÕ option is given, your program should give the details of symbolic links themselves as the Ô-LÕ option does for the real ls
23.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/20 UNIXSystems Programming II Session 2 process handling ¥ UNIX processes and forking ¥ fork system call ¥ exec system call ¥ death of process ¥ kill ¥ fork and I/O using it
24.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/21 A UNIX process UNIX process: ¥ identified by process id (pid) ¥ process includes: r program code r application data r system data p including file descriptors code data system data e.g. file descriptors pid = 597
25.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/22 Forking UNIX 'fork' duplicates process: ¥ copies complete process state: r program data + system data r including file descriptors ¥ code immutable Ð shared $ echo $$ 597 $ (echo $$) 632 $ code data system data 597 code data system data 632
26.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/23 Forking – 2 ¥ old process called the parent ¥ new process called the child ¥ process ids r allocated sequentially r so effectively unique (but do wrap after a very long time) ¥ finding process ids r at the shell prompt: use 'ps' r in a C program: use 'int p = getpid();' r in a shell script: use '$$' N.B. useful for naming temporary files: tmpfile = /tmp/myfile$$
27.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/24 Fork system call pid_t p = fork(); ( pid_t ≈ int ) ¥ if successful r process r successful fork returns: 0 Ð to child process child pid Ð to parent process ⇒ parent and child are different! ¥ negative result on failure
28.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/25 Execution – 1 ¥ parent forks 597 ¬ int i = 3, c_pid = -1; c_pid = fork(); if ( c_pid == 0 ) printf(childn); else if ( c_pid 0 ) printf(parentn); else printf(failedn); DATA i = 3 c_pid = -1 ¥ after fork parent and child identical 597 632 ¬ int i = 3, c_pid = -1; c_pid = fork(); if ( c_pid == 0 ) printf(childn); else if ( c_pid 0 ) printf(parentn); else printf(failedn); ¬ int i = 3, c_pid = -1; c_pid = fork(); if ( c_pid == 0 ) printf(childn); else if ( c_pid 0 ) printf(parentn); else printf(failedn); DATA i = 3 DATA i = 3 c_pid = 632 c_pid = 0 ¥ except for the return value of fork
29.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/26 Execution – 2 ¥ because data are different 597 632 ¬ int i = 3, c_pid = -1; c_pid = fork(); if ( c_pid == 0 ) printf(childn); else if ( c_pid 0 ) printf(parentn); else printf(failedn); ¬ int i = 3, c_pid = -1; c_pid = fork(); if ( c_pid == 0 ) printf(childn); else if ( c_pid 0 ) printf(parentn); else printf(failedn); DATA i = 3 DATA i = 3 c_pid = 632 c_pid = 0 ¥ program execution differs 597 632 ¬ int i = 3, c_pid = -1; c_pid = fork(); if ( c_pid == 0 ) printf(childn); else if ( c_pid 0 ) printf(parentn); else printf(failedn); ¬ int i = 3, c_pid = -1; c_pid = fork(); if ( c_pid == 0 ) printf(childn); else if ( c_pid 0 ) printf(parentn); else printf(failedn); DATA i = 3 DATA i = 3 c_pid = 632 c_pid = 0 ¥ so parent and child behaviour diverge
30.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/27 exec system call execv(char *prog, char **argv); ¥ replaces the current process with prog ¥ never returns except on failure ¥ argv is passed to the 'main' of prog N.B. needs at least argv[0] set to program name ¥ new process: r code Ð replaced by prog r data Ð reinitialised r system data Ð partly retained f file descriptors still open ¥ several variants (execl, execvp, . . . ) ¥ often used after fork to spawn a fresh program
31.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/28 exec vs. fork ¥ fork duplicates process ¥ exec replaces process code data system 597 code data system 632 code data system 597 code data system 493 code data system 493 fork exec ¥ fork child shares open file descriptors ¥ exec-ed process retains open fds
32.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/29 death of a forked process ¥ when parent dies r children become orphans ! r system init process 'adopts' them ¥ when child dies r parent (or init) informed by signal ( SIGCHLD ) r child process partly destroyed r rump retained until parent 'reaps' Ð using waitor wait3system call r until then child is 'zombie' Ð ps says exiting or defunct N.B. zombie state necessary so parent can discover which child died
33.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/30 wait ¥ if parent does not reap children . . . they stay zombies forever . . . system resources may run out ¥ reap using variants of wait union wait status; int pid = wait(status); r block until a child has died return pid of deceased child int sysv(char *prog,char **argv) { union wait status; int pid = fork(); if ( pid 0 ) return -1; if ( pid == 0 ) execvp(prog,argv); if ( wait(status) != pid ) return -1; return 0; } ¥ wait3 similar, but with more options
34.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/31 SIGCHLD wait3 ¥ wait blocks $ no good for concurrent execution SIGCHILD says when child has died x first catch your signal signal(SIGCHLD,my_reaper); ¥ function 'my_reaper' called when signal arrives y then reap a child int my_reaper() { union wait status; while( wait3(status,WNOHANG,NULL) = 0 ); } ¥ use WNOHANG so that wait3 doesn't block ¥ loop to reap multiple children
35.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/32 kill system call int kill(int pid, int sig); ¥ sends the signal sig to process pid ¥ target process Ð pid r must have same effective user id (usually launched by same user) r super user programs can kill anyone! r special case: pid == -1 ⇒ broadcast (kill nearly everyone) donÕt worry Ð super user only ¥ kill? r only kills the process if it is not caught (using signal system call) r but some signals can never be caught ¥ self-destruct r a process can send signals to itself!
36.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/33 fork and I/O low-level I/O ¥ open file descriptors shared so: r output is merged r input goes to first read Ð accept similar r close down may be delayed until all processes close fd ⇒ close all unwanted fds or use ioctlto set close-on-exec high-level I/O ¥ C stdio is buffered: r duplicated at fork r may get flushed after fork ⇒ duplicate writes stderr OK Ð unbuffered ⇒ careful with stdio use stderr or setbuff(fd,NULL)
37.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/34 ³³³³ Hands on ³³³³ look at the program fork-test.c in prog2 check you understand how it works copy it into your directory and compile and run it write a test program for the sysv function on the wait slide get it to run /bin/cat on a test file the argv structure you pass to sysv will look something like this: static char *ex_argv[3] = { cat, tom, NULL }; try redirecting the output by opening a file and then using dup2: int fd = open( dick, O_WRONLY | O_CREAT ); dup2(fd,1);
38.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/35 UNIXSystems Programming II Session 3 inter-process communication ¥ shell pipes ¥ building pipes ¥ psuedo-terminals ¥ sockets ¥ socket I/O and deadlock using it
39.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/36 IPC ¥ processes may need to communicate Ð inter-process communication (IPC) ¥ different circumstances: r local machine or over network? r forked from single process? r terminal handling required? ¥ different mechanisms: r pipes Ð local, forked no terminal handler r pseudo-terminals Ð local, not necessarily forked terminal handler r sockets Ð remote (e.g. TCP/IP) no terminal handler
40.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/37 shell pipes ¥ UNIX shell pipes join the standard output of one command to the standard input of another $ head -5 fred | cut -c1-10 ¥ commands run at the same time ¥ standard error from both are mixed together (!) errors 'fred' output head -5 col -c1-10 ¥ shell pipes are a special case of a general mechanism ¥ DOS has pipes too . . . . . . but just a shorthand for hidden temporary files!
41.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/38 pipe system call int p[2]; int res = pipe(p); ¥ returns a pair of file descriptors ¥ connected: p[1]→ p[0] Ð any data written to p[1] . . . . . . appears as input to p[0] ¥ buffered within operating system ¥ initially connects process to itself int p[2], res, n; char buff[100] res = pipe(p); write(p[1],hello world,11); n = read(p[0],buff,100); write(1,buff,n); ¥ not particularly useful!
42.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/39 linking processes with pipes ¥ pipe cannot be used to link existing processes ¥ but can link process as they fork ¥ uses the fact that forked file descriptors are shared x use pipe system call to link process to itself process p[1] p[0] OS buffer y use fork Ð file descriptors shared ⇒ both parent and child can: read from p[0] and write to p[1] process p[1] p[0] OS buffer child p[1] p[0] fork
43.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/40 linking with pipes – 2 z one side closes p[0] and the other closes p[1] process p[1] p[0] OS buffer child p[1] p[0] { now the two processes can communicate process p[1] OS buffer child p[0] Note: ¥ buffer full ⇒ write(p[1] ...) will block ¥ buffer empty ⇒ read(p[0] ...) will block ¥ p[1] closed and buffer empty ⇒ read(p[0] ...) returns 0 (end of file)
44.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/41 piping to and from programs ¥ typical use of pipe: r pipe created between parent and child (stages x to {) r child uses dup2to connect p[0]to stdin r child execs another program ÒXÓ r output of parent (through p[1]) → standard input of X ¥ child code: close(p[1]); /* output side */ dup2(p[0],0); close(p[0]); /* still open as 0 */ exec(X); ¥ alternatively: r parent retains input side of pipe p[0] child connects output side to standard output ⇒ parent captures program output r open two pipes for both
45.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/42 pseudo-terminals ¥ some programs need a terminal e.g. screen editors or behave differently with pipes e.g. ls on Berkeley based UNIX ¥ pseudo-terminals: r have terminal driver between end-points r allow remote processes to connect ¥ uses: r window managers r remote logins over network /dev client server shell network pseudo-terminalremote terminal
46.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/43 pseudo-terminals – 2 ¥ special ÔvirtualÕ devices in /dev ¥ in pairs r /dev/ttyp[a-z][0-9] Ð slave end r /dev/ptyp[a-z][0-9] Ð controller end ¥ connection r output to /dev/ttyp?? → input of corresponding /dev/ptyp?? r output to /dev/ptyp?? → input of corresponding /dev/ttyp?? r both liable to transformation by tty driver ¥ asymmetry r /dev/ttyp?? Ð behaves like the computer end of a tty including stty options r /dev/ptyp?? Ð behaves like the user end of a tty
47.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/44 opening pseudo-terminals ¥ use normal open system call r control end program int fd = open(/dev/ptypb7,2); r slave end program int tty_fd = open(/dev/ttypb7,2); ¥ full-duplex connection Ð can read or write to either end ¥ finding a pseudo-terminal r control end often ÔfishesÕ Ð tries to open each pty in turn r how does the other process know which tty? Ð often forked after fishing (just like pipes!) Ð other form of IPC
48.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/45 sockets ¥ generic connection mechanism r networks: e.g. Internet (TCP/IP) r local: e.g. UNIX domain ÔsocketpairÕ ¥ roots r original Berkeley TCP/IP implementation ¥ features r central abstraction - the socket - an end-point like an electrical connector r uses normal read/write system calls r sockets associated with UNIX file descriptors but some not for normal I/O r some extra system calls especially fot TCP/IP ¥ normally bi-directional r read and write to same file descriptor ? close one direction special socket call shutdown(sock,dir)
49.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/46 socketpair system call ¥ the simplest sockets have no network connection int s[2]; int res = socketpair(s,AF_UNIX,SOCK_STREAM); ¥ returns a pair of sockets (file descriptors) ¥ like pipes, but both bidirectional: s[1] ↔ s[0] int s[2], res, n; char buff[100] res = socketpair(s,AF_UNIX,SOCK_STREAM); write(s[1],one way,7); n = read(s[0],buff,100); write(1,buff,n); write(s[0],and back again,14); n = read(s[1],buff,100); write(1,buff,n); ¥ again use fork to establish connected processes ¥ in fact pipe now implemented using socketpair
50.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/47 read write with sockets ¥ pipes and pseudo-terminals similar ¥ reading may block r reading from a file either: (i) succeeds (ii) gets end of file (ret = 0) r reading from a socket waits until (i) (network) data received (ret 0) (ii) connection closed (ret = 0) (iii) network error (ret 0) ¥ writing may block r writing to a socket may (i) send to the network (ret 0) (ii) find connection is closed (ret = 0) (iii) network error (ret 0) r it may return instantly r but may block if buffers are full $ BEWARE Ð may work during testing (sufficient buffer space) then fail in use (block and deadlock when buffers full)
51.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/48 deadlock ¥ cycles of pipes/sockets can deadlock process 1 buffer process 2 buffer process 3 buffer ¥ OK so long as buffers donÕt fill up ¥ if everyone writes faster then they read everyone waits for everyone else! ¥ duplex channels similar ⇒ donÕt use blocking I/O
52.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/49 Hands on write a test program that Ôtalks to itselfÕ using a pipe, as in the example code on the pipe system call slide do a similar a test with a socket pair you are all logged on to the same machine, so should be able to communicate using pseudo- terminals try it from the shell; one of you types: cat /dev/ttypn (for some suitably chosen n!) and the other types: cat /dev/ptypn have a nice chat!: what happens if you try doing the cats in the opposite order? if there is time, try using fork, exec and pipeto perform the equivalent of the shell command: ls /dev | head -30
53.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/50 UNIXSystems Programming II Session 4 non-blocking I/O and select ¥ UNIX events ¥ setting timers ¥ polling ¥ select system call ¥ signals and select proxy server
54.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/51 UNIX Events Computational programs: ¥ busy most of the time ¥ read/write when they are ready Interactive programs: ¥ servers clients ¥ idle most of the time ¥ respond to events UNIX processes Ð 4 types of event x signal (interrupt) y time (alarm) z input ready read will not block { output can accept (more) data write will not block
55.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/52 Responding to events Events: x signal (interrupt) y time (alarm) z input (read) ready { output (write) ready Responding ¥ interrupt handler Ð xy use signalsystem call use setitimerto send SIGALRM ¥ turntaking Ð y,z{ call read/writewhen ready use sleepfor delays ¥ polling Ð y,z{ use non-blocking read/write use time to do things at specific times ¥ wait for several events use selectsystem call timeout or SIGALRM
56.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/53 setting timers ¥ processes in UNIX have ÔtimersÕ r exactly 3 of them (why 3?!) r like private alarm clocks r precision of milliseconds . . . . . . but not accuracy! ¥ two datatypes struct timeval { Ð single time long tv_sec; Ð in seconds long tv_usec; Ð and milliseconds } struct itimerval { struct timeval it_interval; Ð period of timer struct timeval it_value; Ð next alarm } N.B. it_interval == 0 ⇒ only one alarm ¥ setting a timer struct itimerval value, oldvalue; int which; int res = setitimer(which, value, oldvalue); ¥ which says which timer to use (an int) ¥ when timer expires, process sent SIGALRM ¥ read a timer with getitimer(which, value);
57.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/54 polling in UNIX #include sys/filio.h int flag = 1; ioctl(fd,FIONBIO,flag); ¥ call to ioctl tells system: donÕt block on read/write ¥ polling therefore possible ¥ structure of polling telnet-like client: int flag = 1; ioctl(tty_fd,FIONBIO,flag); ioctl(net_fd,FIONBIO,flag); for(;;) { /* any terminal input? */ n = read(tty_fd,buff,buff_len); if ( n 0 ) { /* yes! do something */ } /* any network input? */ n = read(net_fd,buff,buff_len); if ( n 0 ) { /* yes! do something */ } }
58.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/55 polling pros and cons program is Ôin controlÕ similar to normal programs (i.e. non-interactive programs) $ busy polling consumes CPU time put a sleep in the loop int flag = 1; ioctl(tty_fd,FIONBIO,flag); ioctl(net_fd,FIONBIO,flag); for(;;) { n = read(tty_fd,buff,buff_len); if ( n 0 ) { /* do something */ } n = read(net_fd,buff,buff_len); if ( n 0 ) { /* do something */ } sleep(5); } $ kills interactive performance OK if fast response not critical (e.g. no user interaction)
59.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/56 read write read: ¥ waits on one file descriptor ¥ returns when input data is ready ¥ and reads the data into a buffer read(0,buff,len) write: ¥ waits on one file descriptor ¥ returns when output is possible ¥ and writes the data from the buffer write(1,buff,len)
60.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/57 select select: ¥ waits on many file descriptor ¥ returns when input or output ready ¥ but does no actual I/O + also allows timeout select(width,in_fds,out_fds,err_fds,timeout) ì
61.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/58 select system call – 2 int ret = select(size,in_fds,out_fds,err_fds,timeout); ¥ in_fds, out_fds: Ð bitmaps of file descriptors r in_fds Ð wait for input i.e. read will not block r out_fds Ð wait for output i.e. write will not block ¥ size: Ð sizeofin_fds, out_fds, err_fds ¥ timeout: Ð when to timeout in seconds and milliseconds Returns when: ¥ input ready on one of in_fds (ret 0) ¥ output ready on one of out_fds (ret 0) ¥ error occurs on one of err_fds (ret 0) ¥ timeout expires (ret == 0) ¥ signal has been caught (ret 0) ¥ some other error occurs (ret 0)
62.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/59 select and I/O #include sys/types.h fd_set in_fds, out_fds, err_fds ¥ modified by call: call Ð bit set = wait for file desc return Ð bit set = file desc ready return value from select = number ready ¥ long integer in early UNIX systems in_fds = in_fds || ( 1fd ); ⇒ limit of 32 file descriptors . . . but some systems allow more ¥ now a special fd_set structure actually an array of integers! r setting: FD_ZERO( in_fds ); FD_SET( fd, in_fds ); FD_CLR( fd, in_fds ); r testing: if ( FD_ISSET(fd,in_fds) ) ...
63.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/60 select and I/O – 2 ¥ input r terminal/socket Ð read will not block r passive socket Ð accept will not block ¥ output r terminal/socket Ð write ÔreadyÕ r write relies on system resources r change between select and write? ⇒ write may block c use non-blocking write ¥ can Ôget awayÕ without select on write . . . but dangerous!
64.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/61 select and timeouts #include sys/time.h struct timeval timeout; ¥ timeout.tv_secs timeout.tv_ms Ð maximum time to wait in seconds and ms ¥ if no I/O ready and no signals in time limit then select returns with zero result N.B. in_fds, out_fds, err_fds all zero also ¥ modified by call? r ideally should return time remaining r doesnÕt now . . . . . . but may do one day ⇒ donÕt rely on timeout not being changed reset for each call to select
65.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/62 select and signals ¥ signal occurs during system call: read, write, or select ¥ signal not caught . . . . . . process aborts! ¥ signal caught . . . x relevant handler called y systems call returns with ÔerrorÕ ¥ how do you know? r negative return value r errno set to EINTR ¥ negative return errno ≠ EINTR ⇒ really an error!
66.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/63 example – proxy server ¥ proxy server r monitors Internet traffic to and from server client proxy network server ¥ structure of code x wait for client connection y connect to remote Internet server z loop forever waiting for client or server input: r when client data ready read it send to server echo it to terminal r when server data ready read it send to client echo it to terminal
67.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/64 proxy code – 1 Œ Main loop main(...) { /* establish port */ port_sk = tcp_passive_open(port); /* wait for client to connect */ client_sk = tcp_accept(port_sk); /* only want one client, */ /* so close port_sk */ close(port_sk); /* now connect to remote server */ serv_sk = tcp_active_open(rem_host,rem_port); ret = do_proxy( client_sk, serv_sk ); exit(0); } ¥ basically sets up network connections and then calls do_proxy
68.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/65 proxy code – 2 y perform proxy loop int do_proxy( int client_sk, int serv_sk ) { ¥ first declare and initialise fd bitmaps fd_set read_fds, write_fds, ex_fds; FD_ZERO(read_fds); FD_ZERO(write_fds); FD_ZERO(ex_fds); FD_SET(client_sk,read_fds); FD_SET(serv_sk ,read_fds); ¥ then loop forever for(;;) { int num, len; ¥ copy bitmaps because select modifies them fd_set read_copy = read_fds; fd_set write_copy = write_fds; fd_set ex_copy = ex_fds; static struct timeval timeout = {0,0}; ¥ then call select num = select(MAX_FD, read_copy, write_copy, ex_copy, timeout); ¯ check return Ð z, { | at this point } return 0; }
69.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/66 proxy code – 3 z check for signals, errors and timeout ¥ first check for signals: in this case, we are not expecting any so return in general, we may need to do some processing following the interrupt it is usually better for the interrupt to set some flag and let the main loop do most of the work this reduces the risk of stacked interrupts and mistakes in concurrent access to data structures if (num 0 errno == EINTR ) { /* stopped by signal */ perror(EINTR); return 1; } ¥ if there has been no signal num 0 is an error if (num 0 ) { /* not stopped by signal */ perror(select); return 1; } ¥ if num is zero then a timeout has occurred again, in this case no processing but in general this is the opportunity for animation or other periodic activity if ( num == 0 ) continue; /* timeout */
70.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/67 proxy code – 4 { check for client input client ready if bit is set in read_copy if ( FD_ISSET(client_sk,read_copy) ) { int len = read( client_sk, buff, buf_len ); ¥ on end of file or error exit the loop if ( len = 0 ) { /* errororclose */ close(serv_sk); return len; } ¥ if there is some input data, write it to the server and log it else { write(serv_sk,buff,len); log_from_client( buff, len ); } } | server input similar if ( FD_ISSET(serv_sk ,read_copy) ) { int len = read( serv_sk , buff, buf_len ); if ( len = 0 ) { /* errororclose */ close(client_sk); return len; } else { write(client_sk,buff,len); log_from_server( buff, len ); } }
71.
UNIXSystems ProgrammingII Short Course
Notes Alan Dix © 1996 II/68 Hands on h the proxy server is a bit similar to a telnet client both open a connection to a remote server both echo from the user to the server . . . . . . and from the server to the user the major difference is that the proxy server operates on the Ôother endÕ of a network connection you are going make a simple telnet-like client copyproxy.c and makefile from prog copyproxy.c and call it raw-client.c h proxy.c reads and writes the client socket you want to read from standard input (0) and write to standard output (1) proceed as follows: x remove the code to open the client connection (passive open and accept) y remove the parameter to do_proxy which corresponds to the client socket z modify the FD_SET calls so that selectwaits for standard input (0) rather than the client { change all read calls from the client so that they read from standard input (0) | change all write calls to the client so that they write to standard output (1) now compile and run your raw client, e.g.: raw-client biggles 7 (biggles is another UNIX box, 7 is the TCP/IP echo server)
Descargar ahora