伊人久久成人,久久一区二区三区av,欧美性色视频在线

Fri, 29 Dec 2006 03:07:00 GMT

最�q�看��C��关于旉��上面的几个变量：timeval,time_t,tm。请了解的详�l�说说它们的定义和相关的调用函数�Q�让大家一��h��学习�Q�呵��c�?img src ="http://www.shnenglu.com/sscchh-2000/aggbug/16969.html" width = "1" height = "1" />

史传�U?/a> 2006-12-29 11:07 发表评论

Unix�|�络�~�程�W�三�?卷一:套接字联�|�API学习�W�记(3)

Wed, 17 May 2006 01:42:00 GMT

TCP�q�接的徏立和�l�止

��Z��帮助我们理解conncet�Q�accept�Q�close�q�几个函敎ͼ�以及使用netstat工具来调试TCP应用�E�序�Q�我们必��ȝ��解TCP�q�接是如何徏立和�l�止的和TCP状态�{换图�?br />

三次握手

当一个TCP�q�接建立�Ӟ��发生了以下场景：

The server must be prepared to accept an incoming connection. This is normally done by calling socket, bind, and listen and is called a passive open.
The client issues an active open by calling connect. This causes the client TCP to send a "synchronize" (SYN) segment, which tells the server the client's initial sequence number for the data that the client will send on the connection. Normally, there is no data sent with the SYN; it just contains an IP header, a TCP header, and possible TCP options (which we will talk about shortly).
The server must acknowledge (ACK) the client's SYN and the server must also send its own SYN containing the initial sequence number for the data that the server will send on the connection. The server sends its SYN and the ACK of the client's SYN in a single segment.
The client must acknowledge the server's SYN.

最��需要三�ơ包交换�Q�因此称作TCP的三�ơ握手，如下图所�C�：
囄��Q� TCP 的三�ơ握�?/p>

We show the client's initial sequence number as J and the server's initial sequence number as K. The acknowledgment number in an ACK is the next expected sequence number for the end sending the ACK. Since a SYN occupies one byte of the sequence number space, the acknowledgment number in the ACK of each SYN is the initial sequence number plus one. Similarly, the ACK of each FIN is the sequence number of the FIN plus one.

An everyday analogy for establishing a TCP connection is the telephone system [Nemeth 1997]. The socket function is the equivalent of having a telephone to use. bind is telling other people your telephone number so that they can call you. listen is turning on the ringer so that you will hear when an incoming call arrives. connect requires that we know the other person's phone number and dial it. accept is when the person being called answers the phone. Having the client's identity returned by accept (where the identify is the client's IP address and port number) is similar to having the caller ID feature show the caller's phone number. One difference, however, is that accept returns the client's identity only after the connection has been established, whereas the caller ID feature shows the caller's phone number before we choose whether to answer the phone or not. If the DNS is used (Chapter 11), it provides a service analogous to a telephone book. getaddrinfo is similar to looking up a person's phone number in the phone book. getnameinfo would be the equivalent of having a phone book sorted by telephone numbers that we could search, instead of a book sorted by name.

TCP 选项

Each SYN can contain TCP options. Commonly used options include the following:

MSS option. With this option, the TCP sending the SYN announces its maximum segment size, the maximum amount of data that it is willing to accept in each TCP segment, on this connection. The sending TCP uses the receiver's MSS value as the maximum size of a segment that it sends. We will see how to fetch and set this TCP option with the TCP_MAXSEG socket option (Section 7.9).
Window scale option. The maximum window that either TCP can advertise to the other TCP is 65,535, because the corresponding field in the TCP header occupies 16 bits. But, high-speed connections, common in today's Internet (45 Mbits/sec and faster, as described in RFC 1323 [Jacobson, Braden, and Borman 1992]), or long delay paths (satellite links) require a larger window to obtain the maximum throughput possible. This newer option specifies that the advertised window in the TCP header must be scaled (left-shifted) by 0�?4 bits, providing a maximum window of almost one gigabyte (65,535 x 2¹⁴). Both end-systems must support this option for the window scale to be used on a connection. We will see how to affect this option with the SO_RCVBUF socket option (Section 7.5).
To provide interoperability with older implementations that do not support this option, the following rules apply. TCP can send the option with its SYN as part of an active open. But, it can scale its windows only if the other end also sends the option with its SYN. Similarly, the server's TCP can send this option only if it receives the option with the client's SYN. This logic assumes that implementations ignore options that they do not understand, which is required and common, but unfortunately, not guaranteed with all implementations.
Timestamp option. This option is needed for high-speed connections to prevent possible data corruption caused by old, delayed, or duplicated segments. Since it is a newer option, it is negotiated similarly to the window scale option. As network programmers there is nothing we need to worry about with this option.

These common options are supported by most implementations. The latter two are sometimes called the "RFC 1323 options," as that RFC [Jacobson, Braden, and Borman 1992] specifies the options. They are also called the "long fat pipe options," since a network with either a high bandwidth or a long delay is called a long fat pipe. Chapter 24 of TCPv1 contains more details on these options.

TCP �q�接的终�?/h4>
TCP建立旉��要三�ơ通知�Q�而终止一个TCP�q�接旉��要四�ơ通知�?br />One application calls `close` first, and we say that this end performs the active close. This end's TCP sends a FIN segment, which means it is finished sending data.
The other end that receives the FIN performs the passive close. The received FIN is acknowledged by TCP. The receipt of the FIN is also passed to the application as an end-of-file (after any data that may have already been queued for the application to receive), since the receipt of the FIN means the application will not receive any additional data on the connection.
Sometime later, the application that received the end-of-file will `close` its socket. This causes its TCP to send a FIN.
The TCP on the system that receives this final FIN (the end that did the active close) acknowledges the FIN.
Since a FIN and an ACK are required in each direction, four segments are normally required. We use the qualifier "normally" because in some scenarios, the FIN in Step 1 is sent with data. Also, the segments in Steps 2 and 3 are both from the end performing the passive close and could be combined into one segment. We show these packets in Figure 2.3.
Figure 2.3. Packets exchanged when a TCP connection is closed.
A FIN occupies one byte of sequence number space just like a SYN. Therefore, the ACK of each FIN is the sequence number of the FIN plus one.
Between Steps 2 and 3 it is possible for data to flow from the end doing the passive close to the end doing the active close. This is called a half-close and we will talk about this in detail with the `shutdown` function in Section 6.6.
The sending of each FIN occurs when a socket is closed. We indicated that the application calls `close` for this to happen, but realize that when a Unix process terminates, either voluntarily (calling `exit` or having the `main` function return) or involuntarily (receiving a signal that terminates the process), all open descriptors are closed, which will also cause a FIN to be sent on any TCP connection that is still open.
Although we show the client in Figure 2.3 performing the active close, either end—the client or the server—can perform the active close. Often the client performs the active close, but with some protocols (notably HTTP/1.0), the server performs the active close.

TCP 状态�{换图

关于TCP�q�接的徏立和�l�止操作可以�׃��个状态�{换图来详�l�说明，如下图所�C�：
囄��Q�TCP 状态�{换图

There are 11 different states defined for a connection and the rules of TCP dictate the transitions from one state to another, based on the current state and the segment received in that state. For example, if an application performs an active open in the CLOSED state, TCP sends a SYN and the new state is SYN_SENT. If TCP next receives a SYN with an ACK, it sends an ACK and the new state is ESTABLISHED. This final state is where most data transfer occurs.

The two arrows leading from the ESTABLISHED state deal with the termination of a connection. If an application calls close before receiving a FIN (an active close), the transition is to the FIN_WAIT_1 state. But if an application receives a FIN while in the ESTABLISHED state (a passive close), the transition is to the CLOSE_WAIT state.

We denote the normal client transitions with a darker solid line and the normal server transitions with a darker dashed line. We also note that there are two transitions that we have not talked about: a simultaneous open (when both ends send SYNs at about the same time and the SYNs cross in the network) and a simultaneous close (when both ends send FINs at the same time). Chapter 18 of TCPv1 contains examples and a discussion of both scenarios, which are possible but rare.

One reason for showing the state transition diagram is to show the 11 TCP states with their names. These states are displayed by netstat, which is a useful tool when debugging client/server applications. We will use netstat to monitor state changes in Chapter 5.

观察包（Watching the Packets�Q?/h4>
下土昄��了一个TCP�q�接实际发生的包交换情况�Q�连接徏立，数据传输和连接终止。在每一端传输的时候，也给��Z��TCP状态。�?br />TCP �q�接的包交换
The client in this example announces an MSS of 536 (indicating that it implements only the minimum reassembly buffer size) and the server announces an MSS of 1,460 (typical for IPv4 on an Ethernet). It is okay for the MSS to be different in each direction (see Exercise 2.5).
Once a connection is established, the client forms a request and sends it to the server. We assume this request fits into a single TCP segment (i.e., less than 1,460 bytes given the server's announced MSS). The server processes the request and sends a reply, and we assume that the reply fits in a single segment (less than 536 in this example). We show both data segments as bolder arrows. Notice that the acknowledgment of the client's request is sent with the server's reply. This is called piggybacking and will normally happen when the time it takes the server to process the request and generate the reply is less than around 200 ms. If the server takes longer, say one second, we would see the acknowledgment followed later by the reply. (The dynamics of TCP data flow are covered in detail in Chapters 19 and 20 of TCPv1.)
We then show the four segments that terminate the connection. Notice that the end that performs the active close (the client in this scenario) enters the TIME_WAIT state. We will discuss this in the next section.
It is important to notice in Figure 2.5 that if the entire purpose of this connection was to send a one-segment request and receive a one-segment reply, there would be eight segments of overhead involved when using TCP. If UDP was used instead, only two packets would be exchanged: the request and the reply. But switching from TCP to UDP removes all the reliability that TCP provides to the application, pushing lots of these details from the transport layer (TCP) to the UDP application. Another important feature provided by TCP is congestion control, which must then be handled by the UDP application. Nevertheless, it is important to understand that many applications are built using UDP because the application exchanges small amounts of data and UDP avoids the overhead of TCP connection establishment and connection termination.

TIME_WAIT 状�?/h3>

毫无疑问�Q�关于网�l�编�E�中最让�h误解点之一��是 TIME_WAIT 状态�?在一端调用了close之后�Q�该端维持这个状态的旉��Z��倍最大段生存旉��Q?span class="docEmphasis">maximum segment lifetime (MSL)�Q��?/h3>
Every implementation of TCP must choose a value for the MSL. The recommended value in RFC 1122 [Braden 1989] is 2 minutes, although Berkeley-derived implementations have traditionally used a value of 30 seconds instead. This means the duration of the TIME_WAIT state is between 1 and 4 minutes. The MSL is the maximum amount of time that any given IP datagram can live in a network. We know this time is bounded because every datagram contains an 8-bit hop limit (the IPv4 TTL field in Figure A.1 and the IPv6 hop limit field in Figure A.2) with a maximum value of 255. Although this is a hop limit and not a true time limit, the assumption is made that a packet with the maximum hop limit of 255 cannot exist in a network for more than MSL seconds.
The way in which a packet gets "lost" in a network is usually the result of routing anomalies. A router crashes or a link between two routers goes down and it takes the routing protocols seconds or minutes to stabilize and find an alternate path. During that time period, routing loops can occur (router A sends packets to router B, and B sends them back to A) and packets can get caught in these loops. In the meantime, assuming the lost packet is a TCP segment, the sending TCP times out and retransmits the packet, and the retransmitted packet gets to the final destination by some alternate path. But sometime later (up to MSL seconds after the lost packet started on its journey), the routing loop is corrected and the packet that was lost in the loop is sent to the final destination. This original packet is called a lost duplicate or a wandering duplicate. TCP must handle these duplicates.
There are two reasons for the TIME_WAIT state:
To implement TCP's full-duplex connection termination reliably
To allow old duplicate segments to expire in the network
The first reason can be explained by looking at Figure 2.5 and assuming that the final ACK is lost. The server will resend its final FIN, so the client must maintain state information, allowing it to resend the final ACK. If it did not maintain this information, it would respond with an RST (a different type of TCP segment), which would be interpreted by the server as an error. If TCP is performing all the work necessary to terminate both directions of data flow cleanly for a connection (its full-duplex close), then it must correctly handle the loss of any of these four segments. This example also shows why the end that performs the active close is the end that remains in the TIME_WAIT state: because that end is the one that might have to retransmit the final ACK.
To understand the second reason for the TIME_WAIT state, assume we have a TCP connection between 12.106.32.254 port 1500 and 206.168.112.219 port 21. This connection is closed and then sometime later, we establish another connection between the same IP addresses and ports: 12.106.32.254 port 1500 and 206.168.112.219 port 21. This latter connection is called an incarnation of the previous connection since the IP addresses and ports are the same. TCP must prevent old duplicates from a connection from reappearing at some later time and being misinterpreted as belonging to a new incarnation of the same connection. To do this, TCP will not initiate a new incarnation of a connection that is currently in the TIME_WAIT state. Since the duration of the TIME_WAIT state is twice the MSL, this allows MSL seconds for a packet in one direction to be lost, and another MSL seconds for the reply to be lost. By enforcing this rule, we are guaranteed that when we successfully establish a TCP connection, all old duplicates from previous incarnations of the connection have expired in the network.
There is an exception to this rule. Berkeley-derived implementations will initiate a new incarnation of a connection that is currently in the TIME_WAIT state if the arriving SYN has a sequence number that is "greater than" the ending sequence number from the previous incarnation. Pages 958�?59 of TCPv2 talk about this in more detail. This requires the server to perform the active close, since the TIME_WAIT state must exist on the end that receives the next SYN. This capability is used by the `rsh` command. RFC 1185 [Jacobson, Braden, and Zhang 1990] talks about some pitfalls in doing this.
一般网�l�程序所使用的协�?/h3>
下图�ȝ��了一些：
Figure 2.19. Protocol usage of various common Internet applications.
The first two applications, `ping` and `traceroute`, are diagnostic applications that use ICMP. `traceroute` builds its own UDP packets to send and reads ICMP replies.
The three popular routing protocols demonstrate the variety of transport protocols used by routing protocols. OSPF uses IP directly, employing a raw socket, while RIP uses UDP and BGP uses TCP.
The next five are UDP-based applications, followed by seven TCP applications and four that use both UDP and TCP. The final five are IP telephony applications that use SCTP exclusively or optionally UDP, TCP, or SCTP.

史传�U?/a> 2006-05-17 09:42 发表评论

母亲节快��C��Q�写点东襉K��给母亲

Fri, 12 May 2006 06:10:00 GMT

母亲节快��C��Q�独自在外求学的我，想给母亲送点�C�物。小时候的记忆中，母亲是一个很严厉的�h�Q�记得有两次被母亲狠狠的揍了。一�ơ是我丢了一块手表，那时候我�q�上��学�Q�就偷偷的把母亲的手表带到学校，�l�果�l�弄丢了。还有一�ơ就是和伙伴玩，�l�果不知道什么原因和他打架了�Q�又被狠狠的揍了一��ѝ��那时候心里想�Q�我现在�q�小�Q�等长大了母亲就打不�q�我了。一�?0几年�q�去了，我还有一�q�就毕业了。在�q�段旉��里，我深�׃��会到了母亲的爱和��x��?br /> 2000�q�那�q�_��我考上了吉林大学，母亲哭了。我��x��亲也是和我一��P��期待着�q�个梦想�Q�而真正实��C��的时候，我们都抑制不了那个喜�(zh��n)�的心情。我��x��亲一定感到很�q�福�Q�她会感到很骄傲的。可能有些�h会想�Q�考了大学有什么了不�v的，现在的大学生跟民工一��P��到处都是。也没有什么好骄傲的吧。可是，在这里我要告诉你�Q�我们那个村�Q�甚至那个乡�Q�在我的记忆中，��出来这样一个大学生�Q�那已经是上个世�U�六七十�q�代的事情了�Q�也��是在中间隔了近30�q�了。你可以惌��那样的场景。母亲能不骄傲嘛�Q�其实母亲的��教现在��x��Q�不是逼着让我学习�Q�而是让我自由的发展，说�v来也怪，��时候我可是一个非常调皮的孩子�Q�整天和伙伴们玩的很疯。到处下��x��|��上树掏鸟�H�。凡是能玩的都玩了。这可能跟母亲的�a�传��n教有关系的。表姐也��N��q�我�Q�“小时候大安��是一��L(f��ng)��的，甚至比我�q�用功，怎么我没有考上大学你去考上了呢�Q�”我也开玩笑的回�{�：其实我玩的时候，头脑�q�是在思考东西呢。其实表姐也是一个很优秀的，只是�׃��家庭的原因，实在太穷了，上完了初中就没有上学了。说到这里，其实在我们村里，或者�Q何一个��I�L(f��ng)��农村�Q�我们这些孩子不是笨�Q�而是真正�׃��安��孩子多，又非常��I�P��又要让每个孩子都能读点书�Q�认上几个字。所以大部分的�h都只能读到初中甚臛_��学没有毕业就辍学了。所以我觉得母亲难能可贵的，��是她的坚持�Q�因为在我初三那�q�毕业的时候，�׃��考试成�W不理惻I��要读高中�q�需要交五千块钱的扩招费。那个时候真是非常艰隄��一步。真可以用摔锅卖铁来形容。所以我很感谢母亲在那么困难的时候能够咬牙撑�q�来了。当然在�q�里�q�要感谢我的�q�爸�q�妈。没有他们的大力支持我也很难走到�q�一步�?br /> 9月䆾�Q�我��d��了生我养我的那个贫瘠的农村，临走的时候，我怀揣着八千块钱�t�往长春的列车上。八千块钱里面现在还清楚的记得：叔叔借的两千�Q�舅舅借的一千，表哥借的一千五�Q�还有姨哥借的一块和姨姐借的五百。剩下的两千是亲朋好友来和喜酒给的。从此开始了我在长春的求学之路。也��是我来到长春之后的两个月左叻I��父亲和母亲也��M��上�v。目的就是打工给我挣来年的学贏V��要知道亲戚安��的生�z�M��q�不好，能支助我�q�么多钱��M��实在不易了。下一�q�的学费当然不可能，也不好意思张口了。先开始说说我的父母吧�Q�来��C��上�v�Q�他们真的不�Ҏ(gu��)��。在老乡的帮助下�Q�很快父母便开始了�W�一份工作。母亲在一个菜市场里面帮别人卖鸡鸭�Q�家��等�Q�一个月500块钱。说��h��q�个可能看上��dƈ不怎么太辛苦。但是我要说�q�个工作我母亲咬牙坚持了两个月最�l�辞��M��。�ؓ什么呢�Q�母亲每天早�?点就起床�Q�然后到菜市场去�Q�这个时候有一车货�Q�由于菜市场是在二楼�Q�母�Ԍ��q�有另外一个阿姨，生活也一定不易，否则�Ҏ(gu��)��不可能来�q�个地方�Q�他们俩��׃��个又一个满载家��的��子往二楼上面爬。这样一个多��时候之后就开始给店主卖，然后把一只又一只的家禽宰杀�Q�然后去皮，�z�干净。就�q�样一�D�|��_��母亲整个��的不成样子了�Q�手皮退了一层又一层。因为实在挺不住了，��d��院治疗。结果辛苦挣了一炚w��几乎都用在了�ȝ��费上面了。再来说说父亲吧�Q�父亲的�W�一份工作是送货�Q�就是那个脚�y�三轮�R�Q�每天送好几次�Q�每�ơ有好几百斤�Q�有时候能辑ֈ�上千斤。一个月也就六七癑֝�钱。就�q�样也挺了几个月便辞了。我�q�有一个妹妹，父母�q�次外出打工�Q�不仅仅是�ؓ了我一个�h的求学。因为我妹妹也高一了，父母不仅仅要供我一个�h�?br /> 来到了长春，一切都是那么新奇，看到了大学生�zȝ��的是太自�׃��。没有老师的管束。也许是我的理想�Q�也许是�q�来之易的求学机会，我仍然想在高中那��P��努力学习�Q�因为我的理��x��要让父母�q�上�q�福的生�z�，不再那么操劳。让乡村们都能够�q�上�q�福的生�z�R��所以我必须努力学习�Q�来学习到真正的本领�Q�这��h��有希望。让我意外的是，�W�一�q�结束之后，我竟然获得了奖助学金�?700块钱。还记得当时我简直不敢相信这是真的。这可是需要母亲日日夜夜拼命挣上一�q�啊�Q�我不知道该说什么好�Q�只能感谢学校对我的��x��。就�q�样�Q�或许是受到了激励，或许我真的很优秀。整个大学四�q�我一��p��得了奖助学金�?6�Q?00块钱�Q�其中奖学金12�Q?00�Q�。再加上中国工商银行��h��14�Q?00。��我顺利的完成了大学四�q�的学业。除了学业之外。我�q�用一部分钱支助我妹妹��M��。另外由于爷爷奶奶年�U�大了，爸妈他们又不在��n辏V��我也给他们寄过几次生活贏V��还记着最多一�ơ是500�Q�那时候爷��L(f��ng)��病了�Q�需要住院。此外由于爸妈在外打工，大姑他们�l�我家种地。我也寄�q�几癑֝�钱。同时也��是减轻了爸妈他们的一点负担吧。整个大学生�z�过得很充实�Q�更让我�q�运的是�Q�遇��C��一个对我有知遇之恩的老师�Q�也��是我现在的导师陈老师�Q�他�Ҏ(gu��)��生活和学习上的帮助让我感�Ȁ不尽�Q�而且我还遇到了一个通情辄��Q�艰苦朴素而又十分漂亮的女孩，也就是我的女朋友霖霖�Q�这几年来真的很感谢她的理解和支持�?br /> 不但我获得了�q�么多的�q�运。我的妹妹也是幸�q�的。由于我在学校和国家的支助下完成了学业，我爸妈辛苦挣的钱��p��够供我妹妹读书了。现在我妹妹已经快毕业了�Q�目前在实习中，虽然每月900块钱�Q�但也是相当不错了。而是现在�q�有一�q�就毕业了，�׃��比较�q�运�Q�读的是公费。每个月�q�能有八�?ji��)百块钱的生�z�补助。从而能让父母他们不要那么操劳了�?br /> 可是�Q�就在前两天�Q�我爸爸跟我说我母亲又去介绍所�׃��100块钱找了一份工作。母亲的工作是给一家医院洗菜，��L(f��ng)��Q�打杂什么的。一个月700块钱�Q�每天早上六点到晚上�?ji��)点。我昨天晚上�l�母亲打了一个电(sh��)话，�{�到快九(ji��)点半才找到母亲的。我坚决要求母亲辞掉工作�Q�可是母亲就说闲着��n也是��|��q�不如忙点呢。一个小时还不到2块钱�Q�母亲还是那��L(f��ng)��乐观。我真的不知道怎么样劝才能劝她辞掉�q�䆾工作�?br /> 其实母亲的��n体�ƈ不好�Q�在我上高中的时候，母亲下地�q�活累出了肝炎，最后�ȝ��d��了，但是也不能太劳篏。而且母亲现在�q�有子宫肌瘤�Q�虽然是良性的�Q�但是也��d��血带来了��n体的严重贫血。我婶婶跟我��_��“你妈有病你和你妹妹怎么不让�Ҏ(gu��)��啊，别�h有病都治�Q�她有病留着�Q�真是奇怪。”其实我妈也��x��Q�不�q�却��_��“等你俩上班挣钱了再治，现在��d��院也��查了�Q�说不要紧，而且手术费也得六七千�Q�根本也没有钱治。”，一个�h的力量真的是那么的微弱啊。我只能盼望我早�Ҏ(gu��)��业，��L��q��母亲�ȝ��。我在这里要��_��“妈�Q�我�׃��Q�是你的坚强支撑了这个家庭，让我们感��C��(zh��n)�伟大的母爱�Q�”�?br /> 看到了我的故事，我希望每一个向我这��L(f��ng)��I�乡娃都能够有一颗奋斗的心，来改变我们的生活。都能够��q��着自己的母�Ԍ��能够期待着明天��好的生�z?..

史传�U?/a> 2006-05-12 14:10 发表评论

Unix�|�络�~�程�W�三�?卷一:套接字联�|�API学习�W�记(2)

Wed, 10 May 2006 03:13:00 GMT

该节主要展示一个简单的[日期旉��]服务器的�E�序�C�Z��.
��1.3 一个简单的日期旉��服务器程序代�?br /> �q�个服务器程序可以�ؓ上一节的客户端提供服务�?br />

 1 #include     "unp.h"

 2 #include     


 3 int

 4 main(int argc, char **argv)

 5 {

 6     int     listenfd, connfd;

 7     struct sockaddr_in servaddr;

 8     char    buff[MAXLINE];

 9     time_t ticks;


10     listenfd = Socket(AF_INET, SOCK_STREAM, 0);


11     bzeros(&servaddr, sizeof(servaddr));

12     servaddr.sin_family = AF_INET;

13     servaddr.sin_addr.s_addr = htonl(INADDR_ANY);

14     servaddr.sin_port = htons(13); /* daytime server */


15     Bind(listenfd, (SA *) &servaddr, sizeof(servaddr));


16     Listen(listenfd, LISTENQ);


17     for ( ; ; ) {

18         connfd = Accept(listenfd, (SA *) NULL, NULL);


19         ticks = time(NULL);

20         snprintf(buff, sizeof(buff), "%.24s\r\n", ctime(&ticks));

21         Write(connfd, buff, strlen(buff));


22         Close(connfd);

23     }

24 }

产生一个TCP套接�?/h4>

`10` 创徏一个TCP套接字，与客��L(f��ng)��一栗��?/h4>

�l�定服务器的�q��ؓ人知的端口到该套接字

11�?5 服务器通过填充�|�络套接字结构体中的端口域，以及服务器的�|�络接口�Q�IP地址�Q�，然后�q�行�l�定�Q�调用bind�Q�。在�q�里指定IP地址为INADDR_ANY�Q��ؓ了让客户端可以连接服务器的�Q一�|�络接口�Q�因为服务器可能有多块网卡，也就对应了多个IP地址�Q�，也就是说如果服务器有两个IP地址�Q�客��L(f��ng)��q�接��M��IP地址卛_��。后�l�章节中介绍了如何限制客��L(f��ng)��q�接��C��个固定的接口上�?/p>

转换为监听套接字

16 通过调用listen�Q�一个套接字��p�{换�ؓ监听套接字，�q�就是说该套接字负责接收来自客户端的�q�接��h��Q�而�ƈ不真正与客户端进行信息传输�?br />帔R��LISTENQ 是在头文�?tt>unp.h中定义的�Q�它是指能够同时监听客户端连接的个数。不��过LISTENQ的客��L(f��ng)��同时�q�接服务器，它们会在一个队列中排队�Q�来�{�待服务器的处理。后�l�章节有更详�l�的讨论�?br />
接收客户端连接，发送回�?/p>

17�?1 一般地�Q�服务器�q�程在调用accept之后�q�入到睡眠状态，�{�待着客户端地�q�接��h��. 一个TCP�q�接通过一个称��Z��Ҏ(gu��)��手来建立�Q�当三方握手完成之后�Q�accept调用�q�回。返回值是一个新的套接字描述�W�（一个整数值connfd�Q�，�q�个新的套接字负责与客户端进行通讯。对于每一个客��L(f��ng)��地连接，accept都返回一个新的套接字描述�W�。整本书使用的无限��@环风格是�q�样的：

for ( ; ; ) {
    . . .
}

当前旉��和日期通过调用库函数time来获得，�q�且通过调用ctime�q�行转换�Q��得我们能够直观的阅读。如下：
Mon May 26 20:58:40 2003

�l�止�q�接

22 客户端调用close之后�Q�服务器关闭�q�接。这时候引起了一个TCP�q�接�l�止序列�Q�一个FIN发送到每一端，同时每一个FIN都要被另一端确认。在后面章节中将会对TCP�q�接建立时候的三方握手以及TCP�q�接�l�止时候的四包交换有更详细的讨论�?br /> 以上�l�出的客��L(f��ng)��和服务器版本都是协议相关的（IPv4�Q�，在后面将会给��Z��个协议无关的版本�Q�IPv4和IPv6都适用�Q�主要通过使用getaddrinfo函数�Q��?br /> 最后需要补充的一�Ҏ(gu��)��Q�在以上涉及到Socket API调用的时候，每个函数的第一个字母变成了大写�Q�其意义和小写开头的是一��L(f��ng)��Q�只不过多了一个错误处理�Ş了�?/p>

史传�U?/a> 2006-05-10 11:13 发表评论

Tue, 09 May 2006 13:39:00 GMT

D.3 Standard Error Functions

We define our own set of error functions that are used throughout the text to
handle error conditions. The reason for using our own error functions is to
let us write our error handling with a single line of C code, as in

if (error condition)
    err_sys (printf format with any number of arguments);

instead of

if (error condition) {
    char buff [2002];
    snprintf(buff, sizeof (buff), printf format 
    with any number of arguments);
    perror(buff);
    exit (1);
}

Our error functions use the variable-length argument list facility from ANSI C.
See Section 7.3 of [Kernighan and Ritchie 1988] for additional details.

Figure D.3 lists the differences between the various error functions.
If the global integer daemon_proc is nonzero, the message is passed to
syslog with the indicated level; otherwise, the error is output to standard error.
Figure D.3. Summary of our standard error functions.

Figure D.4 shows the first five functions from Figure D.3.

Figure D.4 Our standard error functions.

lib/error.c

 1 #include    "unp.h"
 2 #include              /* ANSI C header file */
 3 #include              /* for syslog() */

 4 int     daemon_proc;            /* set nonzero by daemon_init() */

 5 static void err_doit(int, int, const char *, va_list);

 6 /* Nonfatal error related to system call
 7  * Print message and return */

 8 void
 9 err_ret(const char *fmt, ...)
10 {
11     va_list ap;

12     va_start(ap, fmt);
13     err_doit(1, LOG_INFO, fmt, ap);
14     va_end(ap);
15     return;
16 }

17 /* Fatal error related to system call
18  * Print message and terminate */

19 void
20 err_sys(const char *fmt, ...)
21 {
22     va_list ap;

23     va_start(ap, fmt);
24     err_doit(1, LOG_ERR, fmt, ap);
25     va_end(ap);
26     exit(1);
27 }

28 /* Fatal error related to system call
29  * Print message, dump core, and terminate */

30 void
31 err_dump(const char *fmt, ...)
32 {
33     va_list ap;

34     va_start(ap, fmt);
35     err_doit(1, LOG_ERR, fmt, ap);
36     va_end(ap);
37     abort();                    /* dump core and terminate */
38     exit(1);                    /* shouldn't get here */
39 }

40 /* Nonfatal error unrelated to system call
41  * Print message and return */

42 void
43 err_msg(const char *fmt, ...)
44 {
45     va_list ap;

46     va_start(ap, fmt);
47     err_doit(0, LOG_INFO, fmt, ap);
48     va_end(ap);
49     return;
50 }

51 /* Fatal error unrelated to system call
52  * Print message and terminate */

53 void
54 err_quit(const char *fmt, ...)
55 {
56     va_list ap;

57     va_start(ap, fmt);
58     err_doit(0, LOG_ERR, fmt, ap);

59     va_end(ap);
60     exit(1);
61 }

62 /* Print message and return to caller
63  * Caller specifies "errnoflag" and "level" */

64 static void
65 err_doit(int errnoflag, int level, const char *fmt, va_list ap)
66 {
67     int     errno_save, n;
68     char    buf[MAXLINE + 1];

69     errno_save = errno;         /* value caller might want printed */
70 #ifdef HAVE_VSNPRINTF
71     vsnprintf(buf, MAXLINE, fmt, ap);   * safe */
72 #else
73     vsprintf(buf, fmt, ap);     /* not safe */
74 #endif
75     n = strlen(buf);
76     if (errnoflag)
77         snprintf(buf + n, MAXLINE - n, ": %s", strerror(errno_save));
78     strcat(buf, "\n");

79     if (daemon_proc) {
80         syslog(level, buf);
81     } else {
82         fflush(stdout);         /* in case stdout and stderr are the same */
83         fputs(buf, stderr);
84         fflush(stderr);
85     }
86     return;
87 }

史传�U?/a> 2006-05-09 21:39 发表评论

unp.h文�g内容

Tue, 09 May 2006 12:43:00 GMT

  1 /* Our own header. Tabs are set for 4 spaces, not 8 */
 
  2 #ifndef __unp_h
  3 #define __unp_h

  4 #include    "../config.h"      /* configuration options for current OS */
  5                            /* "../config.h" is generated by configure */

  6 /* If anything changes in the following list of #includes, must change
  7    acsite.m4 also, for configure's tests. */

  8 #include           /* basic system data types */
  9 #include          /* basic socket definitions */
 10 #include            /* timeval{} for select() */
 11 #include                /* timespec{} for pselect() */
 12 #include          /* sockaddr_in{} and other Internet defns */
 13 #include           /* inet(3) functions */
 14 #include    
 15 #include               /* for nonblocking */
 16 #include    
 17 #include    
 18 #include    
 19 #include    
 20 #include    
 21 #include            /* for S_xxx file mode constants */
 22 #include             /* for iovec{} and readv/writev */
 23 #include    
 24 #include    
 25 #include              /* for Unix domain sockets */

 26 #ifdef  HAVE_SYS_SELECT_H
 27 # include         /* for convenience */
 28 #endif

 29 #ifdef  HAVE_SYS_SYSCTL_H
 30 # include   
 31 #endif

 32 #ifdef  HAVE_POLL_H
 33 # include               /* for convenience */
 34 #endif

 35 #ifdef  HAVE_SYS_EVENT_H
 36 # include          /* for kqueue */
 37 #endif

 38 #ifdef  HAVE_STRINGS_H
 39 # include            /* for convenience */
 40 #endif

 41 /* Three headers are normally needed for socket/file ioctl's:
 42  * , , and .
 43  */
 44 #ifdef  HAVE_SYS_IOCTL_H
 45 # include   
 46 #endif
 47 #ifdef  HAVE_SYS_FILIO_H
 48 # include   
 49 #endif
 50 #ifdef  HAVE_SYS_SOCKIO_H
 51 # include   
 52 #endif

 53 #ifdef  HAVE_PTHREAD_H
 54 # include   
 55 #endif

 56 #ifdef  HAVE_NET_IF_DL_H
 57 # include    
 58 #endif

 59 #ifdef  HAVE_NETINET_SCTP_H
 60 #include     
 61 #endif

 62 /* OSF/1 actually disables recv() and send() in  */
 63 #ifdef  __osf__
 64 #undef  recv
 65 #undef  send
 66 #define recv(a,b,c,d)   recvfrom(a,b,c,d,0,0)
 67 #define send(a,b,c,d)   sendto(a,b,c,d,0,0)
 68 #endif

 69 #ifndef INADDR_NONE
 70 #define INADDR_NONE 0xffffffff  /* should have been in  */
 71 #endif

 72 #ifndef SHUT_RD                 /* these three POSIX names are new */
 73 #define SHUT_RD     0           /* shutdown for reading */
 74 #define SHUT_WR     1           /* shutdown for writing */
 75 #define SHUT_RDWR   2           /* shutdown for reading and writing */
 76 #endif

 77 #ifndef INET_ADDRSTRLEN
 78 #define INET_ADDRSTRLEN     16  /* "ddd.ddd.ddd.ddd\0"
 79                                    1234567890123456 */
 80 #endif

 81 /* Define following even if IPv6 not supported, so we can always allocate
 82    an adequately sized buffer without #ifdefs in the code. */
 83 #ifndef INET6_ADDRSTRLEN
 84 #define INET6_ADDRSTRLEN    46  /* max size of IPv6 address string:
 85                    "xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx" or
 86                    "xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:ddd.ddd.ddd.ddd\0"
 87                     1234567890123456789012345678901234567890123456 */
 88 #endif

 89 /* Define bzero() as a macro if it's not in standard C library. */
 90 #ifndef HAVE_BZERO
 91 #define bzero(ptr,n)        memset (ptr, 0, n)
 92 #endif

 93 /* Older resolvers do not have gethostbyname2() */
 94 #ifndef HAVE_GETHOSTBYNAME2
 95 #define gethostbyname2(host,family)     gethostbyname((host))
 96 #endif

 97 /* The structure returned by recvfrom_flags() */
 98 struct unp_in_pktinfo {
 99     struct in_addr ipi_addr;    /* dst IPv4 address */
100     int     ipi_ifindex;        /* received interface index */
101 };

102 /* We need the newer CMSG_LEN() and CMSG_SPACE() macros, but few
103    implementations support them today. These two macros really need
104     an ALIGN() macro, but each implementation does this differently. */
105 #ifndef CMSG_LEN
106 #define CMSG_LEN(size)      (sizeof(struct cmsghdr) + (size))
107 #endif
108 #ifndef CMSG_SPACE
109 #define CMSG_SPACE(size)    (sizeof(struct cmsghdr) + (size))
110 #endif

111 /* POSIX requires the SUN_LEN() macro, but not all implementations define
112    it (yet). Note that this 4.4BSD macro works regardless whether there is
113    a length field or not. */
114 #ifndef SUN_LEN
115 # define    SUN_LEN (su) \
116     (sizeof (*(su)) - sizeof ((su)->sun_path) + strlen((su)->sun_path))
117 #endif

118 /* POSIX renames "Unix domain" as "local IPC."
119    Not all systems define AF_LOCAL and PF_LOCAL (yet). */
120 #ifndef AF_LOCAL
121 #define AF_LOCAL    AF_UNIX
122 #endif
123 #ifndef PF_LOCAL
124 #define PF_LOCAL    PF_UNIX
125 #endif

126 /* POSIX requires that an #include of  define INFTIM, but many
127    systems still define it in . We don't want to include
128    all the STREAMS stuff if it's not needed, so we just define INFTIM here.
129    This is the standard value, but there's no guarantee it is -1. */
130 #ifndef INFTIM
131 #define INFTIM          (-1)     /* infinite poll timeout */
132 #ifdef HAVE_POLL_H
133 #define INFTIM_UNPH              /* tell unpxti.h we defined it */
134 #endif
135 #endif

136 /* Following could be derived from SOMAXCONN in , but many
137    kernels still #define it as 5, while actually supporting many more */
138 #define LISTENQ     1024         /* 2nd argument to listen () */

139 /* Miscellaneous constants */
140 #define MAXLINE     4096         /* max text line length */
141 #define BUFFSIZE    8192         /* buffer size for reads and writes */

142 /* Define some port number that can be used for our examples */
143 #define SERV_PORT        9877    /* TCP and UDP */
144 #define SERV_PORT_STR   "9877"   /* TCP and UDP */
145 #define UNIXSTR_PATH    "/tmp/unix.str" /* Unix domain stream */
146 #define UNIXDG_PATH     "/tmp/unix.dg"  /* Unix domain datagram */

147 /* Following shortens all the typecasts of pointer arguments: */
148 #define SA struct sockaddr

149 #define HAVE_STRUCT_SOCKADDR_STORAGE
150 #ifndef HAVE_STRUCT_SOCKADDR_STORAGE
151 /*
152  * RFC 3493: protocol-independent placeholder for socket addresses
153  */
154 #define __SS_MAXSIZE    128
155 #define __SS_ALIGNSIZE  (sizeof(int64_t))
156 #ifdef HAVE_SOCKADDR_SA_LEN
157 #define __SS_PAD1SIZE   (__SS_ALIGNSIZE - sizeof(u_char) - sizeof(sa_family_t))
158 #else
159 #define __SS_PAD1SIZE   (__SS_ALIGNSIZE - sizeof(sa_family_t))
160 #endif
161 #define __SS_PAD2SIZE   (__SS_MAXSIZE - 2*__SS_ALIGNSIZE)

162 struct sockaddr_storage {
163 #ifdef HAVE_SOCKADDR_SA_LEN
164     u_char  ss_len;
165 #endif
166     sa_family_t ss_family;
167     char    __ss_pad1[__SS_PAD1SIZE];
168     int64_t __ss_align;
169     char    __ss_pad2[__SS_PAD2SIZE];
170 };
171 #endif

172 #define FILE_MODE   (S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH)
173                     /* default file access permissions for new files */
174 #define DIR_MODE    (FILE_MODE | S_IXUSR | S_IXGRP | S_IXOTH)
175                     /* default permissions for new directories */

176 typedef void Sigfunc (int);     /* for signal handlers */

177 #define min(a,b)    ((a) < (b) ? (a) : (b))
178 #define max(a,b)    ((a) > (b) ? (a) : (b))

179 #ifndef HAVE_ADDRINFO_STRUCT
180 # include   "../lib/addrinfo.h"
181 #endif

182 #ifndef HAVE_IF_NAMEINDEX_STRUCT
183 struct if_nameindex {
184     unsigned int if_index;      /* 1, 2, ... */
185     char *if_name;              /* null-terminated name: "le0", ... */
186 };
187 #endif

188 #ifndef HAVE_TIMESPEC_STRUCT
189 struct timespec {
190     time_t tv_sec;              /* seconds */
191     long     tv_nsec;           /* and nanoseconds */
192 };
193 #endif

史传�U?/a> 2006-05-09 20:43 发表评论

Unix�|�络�~�程�W�三�?卷一:套接字联�|�API学习�W�记(1)

Tue, 09 May 2006 12:31:00 GMT

��有关�?sh��)子资料链�?http://www.unpbook.com/
��1.1 介绍

�?.1 �|�络�E�序: 客户端和服务�?/h5>

图�?.2 服务器同时处理多个客��L(f��ng)��

图�?.3 在同一个以太网使用TCP协议通信的客��L(f��ng)��和服务器

图�?.4 �q�域�|�上的客��L(f��ng)��与服务器�Q�例如Web��览器和W(xu��)eb服务器）

��1.2 代码�C�Z��和解�?/p>

1 #include "unp.h"

2 int
3 main(int argc, char **argv)
4 {
5     int     sockfd, n;
6     char    recvline[MAXLINE + 1];
7     struct sockaddr_in servaddr;

8     if (argc != 2)
9         err_quit("usage: a.out ");

10     if ( (sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0)
11         err_sys("socket error");

12     bzero(&servaddr, sizeof(servaddr));
13     servaddr.sin_family = AF_INET;
14     servaddr.sin_port = htons(13); /* daytime server */
15     if (inet_pton(AF_INET, argv[1], &servaddr.sin_addr) <= 0)
16         err_quit("inet_pton error for %s", argv[1]);

17     if (connect(sockfd, (SA *) &servaddr, sizeof(servaddr)) < 0)
18         err_sys("connect error");

19     while ( (n = read(sockfd, recvline, MAXLINE)) > 0) {
20         recvline[n] = 0;        /* null terminate */
21         if (fputs(recvline, stdout) == EOF)
22             err_sys("fputs error");
23     }
24     if (n < 0)
25         err_sys("read error");

26     exit(0);
27 }
其中unp.h是自定义的头文�g�Q?a class="" title="unp.h文�g内容" href="/sscchh-2000/archive/2006/05/09/6836.html" target="_blank">查看源代�?/a>。我们编译�ƈ执行以上代码�Q�得��C��下输出结果：

`solaris %a.out 206.168.112.96 our input`
`Mon May 26 20:58:40 2003 the program's output`

下面��要分析以�?7行代�?后箋章节中有更详�l�的讨论.

包含我们自己的头文�g

1 该头文�g包含了大多数�|�络�E�序所需要的多个头文件以及定义了我们��要使用的一些常�?例如 MAXLINE).

`命��o行参�?/font>`

`2�?` �q�是含有命��o行参数的��d��数定�?即main函数).我们以ANSI C标准来书写代�?

创徏TCP套接�?a name="ch01lev3sec3">

10�?1 socket函数调用创徏了一个网�l�流套接�?(Internet (AF_INET) stream (SOCK_STREAM) socket), 该函数返回一个整数�?它描�q�C��该套接字,以后的函数通过该整数值来使用�q�个套接�?例如connect和read�{�调�?. 其中err_开头的函数是我们自定义的函�?详见�q�里.

��定服务器IP地址和端口号

`12�?6` 我们填充了网�l�套接字地址�l�构(一个名为servaddr的结构体sockaddr_in),填充的信息包括服务器IP地址和端口号.我们把整个结构体首先清零,然后讄��地址族�ؓAF_INET(IPV6该项为AF_INET6),端口号�ؓ13(旉��服务器的端口�?是一个大安��知道的端口号).IP地址由命令行参数指定(argv[1]).IP地址和端口号必须按照指定的格式来填充,我们通过调用htons(��L��字节��到�|�络字节��的转换)和inet_pton(点分十进制到32位整数的转换)两个调用来进行�{化到所需要的格式.

在调用inet_pton的时候可而能会遇到问�?因�ؓ�q�是IPv6新增的函�?以前的IPv4版本可以调用inet_addr来替代该函数.

与服务器建立一个连�?/h4>

`17�?8` TCP套接字调用connect函数,��׃��服务�?main函数的第二个参数)建立了一个TCP�q�接,我们必须指定套接字结构体的第三个参数长度,它��L��让编译器通过C的sizeof�q�算�W�来计算.

��d��和显�C�服务器的回�?/h4>

`19�?5` 调用read来读取服务器的回�?利用标准I/O来显�C��回复信息.此外,在��用TCP的时候我们必��要注意,因�ؓ它是一个没有边界的字节��协�?服务器的回复是一�?6字节的串:

Mon May 26 20 : 58 : 40 2003\r\n

\r 是回�? \n 是换�?

�l�止�E�序
26 exit �l�止�E�序.Unix在一个进�E�结束时候��L��关闭所有打开的描�q�符,因此我们的TCP套接字此时关闭了.
后箋内容��对此有更深入的讨论.

史传�U?/a> 2006-05-09 20:31 发表评论

Fri, 28 Apr 2006 13:47:00 GMT

摘要: 在利�? VC �Q? MFC �~�程的时候，我们往往能碰到这�U�情况：在一个模拟程序中�Q�如有些游戏�Q�，需要实时显�C�Z��些属性的��|��文字或者图形）�Q�这个时候我们可以重新打开一个对话框�Q�可以是一个模态或者非模态的�Q�来昄��q�些信息�Q�本文以模态对话框��Z��Q�简单实现这个技术。以下代码阴影部分是我利�? ClassWizard 加的�Q�蓝色部分是我手工加的。其余是... 阅读全文

史传�U?/a> 2006-04-28 21:47 发表评论

Tue, 25 Apr 2006 13:11:00 GMT

最�q�由于要发布交通仿真程�?TSS)的Demo版，以前�E�序使用的是��Z��SQL2000数据库的数据源，现在需要改成基于Access数据库，但是在改成Access数据库之后，发现仿真的时候，前台客户端程序可以正常读取Access数据库，而后台服务器�q�程不能够正��的��d��数据库。�ؓ什么��用SQL2000数据库的时候没有问题，而��用Access数据库就会出现问题呢�Q�经�q�调试终于找��Z��问题�Q�当模拟开始的时候，前台此时正在保存该方案号的信息到数据库中�Q�而此时后台服务器�E�序也紧接着��d��该方案号信息�Q�此时我觉得可能是Access数据库在处理�q�发的时候出��C��问题。以致于服务器进�E�读取的�Ҏ(gu��)��号信息不正确�Q�接下来的其它信息也��׃��正确了，�q�就造成了不能正常模拟。〔SQL数据库在处理�q�种情况�Ӟ��可能是有一个很好的机制保证了数据的正确性。�?/p>

史传�U?/a> 2006-04-25 21:11 发表评论

VC中访问Access数据库的�Ҏ(gu��)��Q�不需要用户徏立ODBC数据源）

Thu, 13 Apr 2006 05:01:00 GMT

摘要: �׃��目要发布一个单机版�Q�原来用的数据库是大型数据库。需要在单机版中用Access比较方便�Q�另外也不能让用戯��己创建数据源�Q�最�l�的�Ҏ(gu��)��是在程序中直接讉K��Q?.mdb�Q�Access数据库文�Ӟ��下面��要给出在VC6.0中的讉K��Access数据库文件的�Ҏ(gu��)��Q?.....
阅读全文

史传�U?/a> 2006-04-13 13:01 发表评论