没有合适的资源?快使用搜索试试~ 我知道了~
资源推荐
资源详情
资源评论
Beej's Guide to Network Programming
Using Internet Sockets
Version 1.5.4 (17-May-1998)
[http://www.ecst.csuchico.edu/~beej/guide/net]
Intro
Hey! Socket programming got you down? Is this stuff just a little too difficult to figure out from the
man pages? You want to do cool Internet programming, but you don't have time to wade through a
gob of structs trying to figure out if you have to call bind() before you connect(), etc., etc.
Well, guess what! I've already done this nasty business, and I'm dying to share the information with
everyone! You've come to the right place. This document should give the average competent C
programmer the edge s/he needs to get a grip on this networking noise.
Audience
This document has been written as a tutorial, not a reference. It is probably at its best when read by
individuals who are just starting out with socket programming and are looking for a foothold. It is
certainly not the complete guide to sockets programming, by any means.
Hopefully, though, it'll be just enough for those man pages to start making sense... :-)
Platform and Compiler
Most of the code contained within this document was compiled on a Linux PC using Gnu's
gcc
compiler. It was also found to compile on HPUX using gcc. Note that every code snippet was not
individually tested.
Contents:
What is a socket?
Two Types of Internet Sockets
Low level Nonsense and Network Theory
structs--Know these, or aliens will destroy the planet!
Convert the Natives!
IP Addresses and How to Deal With Them
socket()--Get the File Descriptor!
bind()--What port am I on?
connect()--Hey, you!
listen()--Will somebody please call me?
1 of 26 12.03.99 01:21
Beej's Guide to Network Programming file:///C|/Eigene Dateien/Manualz/not ad...ramming; Using Internet Sockets/net.html
accept()--"Thank you for calling port 3490."
send() and recv()--Talk to me, baby!
sendto() and recvfrom()--Talk to me, DGRAM-style
close() and shutdown()--Get outta my face!
getpeername()--Who are you?
gethostname()--Who am I?
DNS--You say "whitehouse.gov", I say "198.137.240.100"
Client-Server Background
A Simple Stream Server
A Simple Stream Client
Datagram Sockets
Blocking
select()--Synchronous I/O Multiplexing. Cool!
More references
Disclaimer and Call for Help
What is a socket?
You hear talk of "sockets" all the time, and perhaps you are wondering just what they are exactly.
Well, they're this: a way to speak to other programs using standard Unix file descriptors.
What?
Ok--you may have heard some Unix hacker state, "Jeez, everything in Unix is a file!" What that
person may have been talking about is the fact that when Unix programs do any sort of I/O, they do it
by reading or writing to a file descriptor. A file descriptor is simply an integer associated with an open
file. But (and here's the catch), that file can be a network connection, a FIFO, a pipe, a terminal, a real
on-the-disk file, or just about anything else. Everything in Unix is a file! So when you want to
communicate with another program over the Internet you're gonna do it through a file descriptor,
you'd better believe it.
"Where do I get this file descriptor for network communication, Mr. Smarty-Pants?" is probably the
last question on your mind right now, but I'm going to answer it anyway: You make a call to the
socket() system routine. It returns the socket descriptor, and you communicate through it using the
specialized send() and recv() ("man send", "man recv") socket calls.
"But, hey!" you might be exclaiming right about now. "If it's a file descriptor, why in the hell can't I
just use the normal read() and write() calls to communicate through the socket?" The short answer
is, "You can!" The longer answer is, "You can, but send() and recv() offer much greater control
over your data transmission."
What next? How about this: there are all kinds of sockets. There are DARPA Internet addresses
(Internet Sockets), path names on a local node (Unix Sockets), CCITT X.25 addresses (X.25 Sockets
that you can safely ignore), and probably many others depending on which Unix flavor you run. This
document deals only with the first: Internet Sockets.
Two Types of Internet Sockets
2 of 26 12.03.99 01:21
Beej's Guide to Network Programming file:///C|/Eigene Dateien/Manualz/not ad...ramming; Using Internet Sockets/net.html
What's this? There are two types of Internet sockets? Yes. Well, no. I'm lying. There are more, but I
didn't want to scare you. I'm only going to talk about two types here. Except for this sentence, where
I'm going to tell you that "Raw Sockets" are also very powerful and you should look them up.
All right, already. What are the two types? One is "Stream Sockets"; the other is "Datagram Sockets",
which may hereafter be referred to as "SOCK_STREAM" and "SOCK_DGRAM", respectively. Datagram
sockets are sometimes called "connectionless sockets" (though they can be connect()'d if you really
want. See connect(), below.
Stream sockets are reliable two-way connected communication streams. If you output two items into
the socket in the order "1, 2", they will arrive in the order "1, 2" at the opposite end. They will also be
error free. Any errors you do encounter are figments of your own deranged mind, and are not to be
discussed here.
What uses stream sockets? Well, you may have heard of the telnet application, yes? It uses stream
sockets. All the characters you type need to arrive in the same order you type them, right? Also,
WWW browsers use the HTTP protocol which uses stream sockets to get pages. Indeed, if you telnet
to a WWW site on port 80, and type "GET pagename", it'll dump the HTML back at you!
How do stream sockets achieve this high level of data transmission quality? They use a protocol called
"The Transmission Control Protocol", otherwise known as "TCP" (see RFC-793 for extremely
detailed info on TCP.) TCP makes sure your data arrives sequentially and error-free. You may have
heard "TCP" before as the better half of "TCP/IP" where "IP" stands for "Internet Protocol" (see
RFC-791.) IP deals with Internet routing only.
Cool. What about Datagram sockets? Why are they called connectionless? What is the deal, here,
anyway? Why are they unreliable? Well, here are some facts: if you send a datagram, it may arrive. It
may arrive out of order. If it arrives, the data within the packet will be error-free.
Datagram sockets also use IP for routing, but they don't use TCP; they use the "User Datagram
Protocol", or "UDP" (see RFC-768.)
Why are they connectionless? Well, basically, it's because you don't have to maintain an open
connection as you do with stream sockets. You just build a packet, slap an IP header on it with
destination information, and send it out. No connection needed. They are generally used for
packet-by-packet transfers of information. Sample applications: tftp, bootp, etc.
"Enough!" you may scream. "How do these programs even work if datagrams might get lost?!" Well,
my human friend, each has it's own protocol on top of UDP. For example, the tftp protocol says that
for each packet that gets sent, the recipient has to send back a packet that says, "I got it!" (an "ACK"
packet.) If the sender of the original packet gets no reply in, say, five seconds, he'll re-transmit the
packet until he finally gets an ACK. This acknowledgment procedure is very important when
implementing SOCK_DGRAM applications.
Low level Nonsense and Network Theory
Since I just mentioned layering of protocols, it's time to talk about how networks really work, and to
show some examples of how SOCK_DGRAM packets are built. Practically, you can probably skip this
section. It's good background, however.
3 of 26 12.03.99 01:21
Beej's Guide to Network Programming file:///C|/Eigene Dateien/Manualz/not ad...ramming; Using Internet Sockets/net.html
Hey, kids, it's time to learn about Data Encapsulation! This is
very very important. It's so important that you might just learn
about it if you take the networks course here at Chico State ;-). Basically, it says this: a packet is
born, the packet is wrapped ("encapsulated") in a header (and maybe footer) by the first protocol (say,
the TFTP protocol), then the whole thing (TFTP header included) is encapsulated again by the next
protocol (say, UDP), then again by the next (IP), then again by the final protocol on the hardware
(physical) layer (say, Ethernet).
When another computer receives the packet, the hardware strips the Ethernet header, the kernel strips
the IP and UDP headers, the TFTP program strips the TFTP header, and it finally has the data.
Now I can finally talk about the infamous Layered Network Model. This Network Model describes a
system of network functionality that has many advantages over other models. For instance, you can
write sockets programs that are exactly the same without caring how the data is physically transmitted
(serial, thin Ethernet, AUI, whatever) because programs on lower levels deal with it for you. The
actual network hardware and topology is transparent to the socket programmer.
Without any further ado, I'll present the layers of the full-blown model. Remember this for network
class exams:
Application
Presentation
Session
Transport
Network
Data Link
Physical
The Physical Layer is the hardware (serial, Ethernet, etc.). The Application Layer is just about as far
from the physical layer as you can imagine--it's the place where users interact with the network.
Now, this model is so general you could probably use it as an automobile repair guide if you really
wanted to. A layered model more consistent with Unix might be:
Application Layer (telnet, ftp, etc.)
Host-to-Host Transport Layer (TCP, UDP)
Internet Layer (IP and routing)
Network Access Layer (was Network, Data Link, and Physical)
At this point in time, you can probably see how these layers correspond to the encapsulation of the
original data.
See how much work there is in building a simple packet? Jeez! And you have to type in the packet
headers yourself using "cat"! Just kidding. All you have to do for stream sockets is send() the data
out. All you have to do for datagram sockets is encapsulate the packet in the method of your choosing
and sendto() it out. The kernel builds the Transport Layer and Internet Layer on for you and the
hardware does the Network Access Layer. Ah, modern technology.
So ends our brief foray into network theory. Oh yes, I forgot to tell you everything I wanted to say
about routing: nothing! That's right, I'm not going to talk about it at all. The router strips the packet
to the IP header, consults its routing table, blah blah blah. Check out the IP RFC if you really really
care. If you never learn about it, well, you'll live.
[Encapsulated Protocols Image]
4 of 26 12.03.99 01:21
Beej's Guide to Network Programming file:///C|/Eigene Dateien/Manualz/not ad...ramming; Using Internet Sockets/net.html
剩余25页未读,继续阅读
资源评论
panda2005
- 粉丝: 0
- 资源: 9
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
- 获取CPU的序列号的Python脚本
- 4354图446546546546546
- 邮箱管理技巧:减少垃圾邮件的9项实用措施
- 三汇SMG 系列D 型模拟网关用户手册,用于三汇SMG系列网关配置
- Siemens Automation Framework V1.2
- 单个IO口检测多个按键
- 汇川EASY32x固件6.3.0.0
- 高分成品毕业设计《基于SSM(Spring、Spring MVC、MyBatis)+MySQL开发个人财务管理系统》+源码+论文+说明文档+数据库
- 高分成品毕业设计《基于SSM(Spring、Spring MVC、MyBatis)+MySQL开发B2C电子商务平台》+源码+论文+说明文档+数据库
- HKJC_3in1_TR_PROD_L3.0R1An_Build10229.apk
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功