转载：GCDAsyncSocket的基本用法

最新推荐文章于 2019-06-01 11:14:56 发布

primer_programer

最新推荐文章于 2019-06-01 11:14:56 发布

阅读量5.6k

点赞数

分类专栏： iOS开发

iOS开发专栏收录该内容

63 篇文章

订阅专栏

原文地址：http://blog.sina.com.cn/s/blog_76950245010159sf.html

server: create->listen->accpet->send/read

client: create->connect->send/read

*Introduction to Socket

In network parlance, a computer is a host for a number of sockets. A Socket is one end of a communication channel called a network connection; the other end is another socket. From its point of view, any socket is local socket, and the socket at the other end of the connection is the remote socket.

To establish the connection, one of the two sockets must contact the other socket. Every socket has an address. The address consists of two parts: the host address and the port number. The host address is the IP address of the computer, and the post number uniquely each socket hosted on the computer.

A computer can have multiple host addresses because it can have multiple networking interface. For example, a computer may be equipped with an ethernet card, a modem, a WiFi card, a VPN connection, Bluetooth

An address such as "google.com" corresponds to a host address, but it's not a host address itself. It is a DNS entry or DNS name, which is converted to a host address by a DNS look-up operation.

HTTP, FTP, XMPP, POP, IMAP, SMTP, DHCP, DNS, VoIP, SIP, RTP, RTCP...

every single one of the protocols is layered on top of another protocol that handles the networking for it. These lower level of protocols handle the majority of the networking aspect so that the application layer protocol (those live above) can focus on the application aspect.

The "application layer protocols" lists above are layered on top of a "transport layer protocol". And of all the protocols above, there are only two transport layer protocol that are used: TCP(Transmission Control Protocol) and UDP(User Datagram Protocol).

UDP: (适合量大)

You can only put a small amount of data in a UDP packet. There is no guarantee that the message will arrive or arrive in order. But it won't waste time retransmitting lost packets. In fact, streaming audio and video are the biggest user of UDP.

UDP also don't need a "connection handshake" (This is the reason why DNS uses UDP).

TCP: (适合高准确性和完整性)

TCP is designed for "long conversation". So there is a initial handshake, it was designed to make the communication reliable on the unreliable network. If you send some information over TCP, and part of it gets lost, the protocol will automatically figure out what got lost and resend it(in a right order). The protocol will also detect congestion in the network, and automatically scale accordingly so everybody can share. There is no limit to the amount of data you can send via TCP.

*GCDAsyncSocket:

socket = [[GCDAsyncSocket alloc]initWithDelegate:self delegateQueue: dispatch_get_main_queue()];

Security(TLS/SSL) is something you setup later. These protocols actually run on top of TCP (they are not part of TCP itself).

Connecting:

The most common way to connect is:

NSError *error = nil;

if(![socket connectToHost:@"deusty.com" onPort: 80 error:&error])

{

NSLog(@"I goofed: %@", error);

}

//The only time the method will return NO is that something obvious prevents it from starting the connect operation. For example, the connect is already connected, or if the delegate was never set.

-(void)socket:(GCDAsyncSocket *)sender didConnectToHost:(NSString *)host port:(UInt16)port{

NSLog(@"Cool, I'm connected! That was easy!");

}

There are several different connect methods:

Optionally specify a connection timeout

Optionally specify the interface to connect: e.g. connect using bluetooth, or connect using WiFi regardless of whether a weird connection is available.

Supply a row socked address instead of a name/port pair.

*Reading & Writing

Queued read/write operations

The tag parameter is echo'd back to you via the various delegate methods. It is designed to help simplify the code in your delegate methods.

The TCP protocol is modeled on the concept of a single continuous stream of unlimited length. It's critical to understand the - and is, in fact, the number one cause of confusion that we see.

Send a few messages over the socket(pseudocode!):

How does the data shows up on the other end:

You are writing the client-side of a protocol where the server sends response with a fixed-length header. The header of all response is exactly 8 bytes. The first 4 bytes contain various flags, etc. And the second 4 bytes contain the length of the response data, which is variable.

After all, not all protocols use a fixed length header. HTTP is one such protocol.

HTTP header has a variable length:

In HTTP, each line in the header is terminated with a CRLF (carriage-return, line-feed: "rn"). Furthermore, the end of the header is marked with 2 back-to-back CRLF's. And the length of the body is specified with the "Content-Length" header field.

There are close to 10 different read methods available. They provide more advanced options such as specify a macLength, or providing your own reading buffer.

**Writing a Server

GCDAsyncSocket also allows you to create a server, and accept incoming connections:

For more concrete example, see the "EchoServer" sample project comes with the repository.

***Reference_GCDAsyncSocket

*Automatic socket acceptance:

If you tell it to accept connections, it will call you with new instances of itself for each connection. You can, of course, disconnect them immediately.

Automatic support for IPv4 and IPv6

SSL/TLS support

One of the more powerful feature of GCDAsyncSocket is its queued architecture. This allows you to control socket when it is convenient to you, and not when the socket tells you it's ready.

In addition to this, you can invoke multiple read/write request as is convenient.

We don't have to wait for that write/read to complete before starting the next one.

***Common Pitfalls

socket.write("Hi, Sandy.");

socket.write("Nice to meet you!")

TCP doesn't treat the writes as a separate data. TCP considers all writes to be part of a single continuous stream. So when you issue the above writes, TCP will simply copy the data into its buffer:

TCP_Buffer = "Hi, Sandy.Nice to meet you!";

And in order to send data over the network, TCP and other network protocols will be required to break data into small pieces that can be transmitted over the medium.

The TCP protocol, at the developer API level, has absolutely no packets or separation data.

*Write:

When you issue a write, the data is simply copied into an underlying buffer within the iOS networking stack.

So when you issue the command, "write the data" the operating system responds with "I have your data, and I will do everything in my power to deliver this to the remote destination."

How do I know when the remote destination has receive my data?

*注：

Server中，read应写在 - ( void )socket:( GCDAsyncSocket *)sender didAcceptNewSocket:( GCDAsyncSocket *)newSocket里面主语为newSocket