socket並發編程視頻教程

Ⅰ 如何提高SOCKET的並發接受連接速度

不知道你用啥語言，網路並發有兩種模式：
老的模式，多進程，新程序大多都不會採用這種方式；
多線程，現代程序，大多採用這種方式。
socket，如果只是鏈接進來，一個鏈接啟動一個線程，有專門的服務進程循環等待。高效的實現，有鏈接到達，比如TCP通訊完成3路握手過程，操作系統，就會把鏈接放到待處理隊列，通知服務進程處理。
而操作系統的未完成鏈接隊列+在處理鏈接隊列是有上限的，這個上限值不確定，根據操作系統不同，可以用程序動態監測到。
因此，如果操作系統鏈接隊列已滿，接受不了新的請求的。一般返回錯誤是connection refused。
想要快速處理並發鏈接，編程角度考慮：
第一要求計算機接受請求要快，一般就採取多線程，服務線程，只負責，啟動新的業務線程，立馬接受下一次請求。
第二為了防止connection refused錯誤發生，業務處理邏輯代碼設計要盡量的快。
第三條，做系統架構設計，再要根據不同的業務量選擇適合的硬體，理論上配置越高越好，一般預算有限的，可以根據業務量提前測算個大概。買配置比測算量高一些的設備即可。一般系統設計，要考慮業務的增長。怎麼測算，需要經驗。
業務量大機器配置好，壯牛拉破車是不行的。設計得再好的架構，寫得再好的代碼。沒有適合的機器。效果達不到期望值的。

Ⅱ 客戶端（大概有100個）使用什麼socket模型好

1、普通的阻塞和非阻塞編程。
利用線程池技術和內存池，SOCKET池技術，基本可以處理一千五百個左右的SOCKET連接，但我們一般使用的機器大約有兩M內存，而在不改變線程堆棧的大小情況下，我們至多可以創建一千七八百個線程，不過也就基本動不了了。我們測試基本到一千個線程左右，機器就很慢了。
還有在WIN-XP-SP2中，對單進程中的線程的並發做了處理，默認是10個，修改的方法網上多的是。
2、SELECT模型（非同步和同步）
這個模型在單線程的情況下默認是64個最大SOCKET連接。你可以修改WINSOCK2.h這個文件中的FD_SETSIZE,但不得超過底層WINSOCK的限制（1024），但如果採用多線程的話，可以處理更多，其實際的最大數量，在單線程里建議不超過1000個，至於多線程，應該也要控制線程切換的效率和數據處理的時間。應該幾千個沒有什麼問題。
3、WSAASYNCSELECT模型
這個模型利用的是消息機制，建議不超過1000個。
4、WSAEVENTSELECT模型
這個模型利用的是事件驅動方式，單個線程不超過64個（WSAWaitForMultipleEvents最多等待64個事件），如果多SOCKET並發宜採用線程池技術，應該幾千個沒什麼問題。
5、重疊IO
應該幾千個沒問題。這個畢竟是下面IOCP的一個技術基礎。
6、IOCP完成埠+重疊IO
這個是解決SOCKET通信的終極武器，可惜只用在WIN上和2000以上，LINUX上好象有一個類似的EPOLL，而且好象比這個還好用，沒具體用過。這個東東解決幾萬個SOCKET並發應該是很輕松，當然你得編程水平和技術得跟上。
從網上查看說這個東西如果使用的伺服器版的操作系統和機器最大可到一百W，太恐怖了吧，那傢伙自己在XP上最大達到了五萬，但不斷出現內存溢出的BUG。他最高到了9W。

Ⅲ socket高並發網路編程服務端有什麼框架

netty;
PayServer.java
package com.miri.pay.scoket;
import io.netty.bootstrap.ServerBootstrap;
import io.netty.channel.ChannelFuture;
import io.netty.channel.ChannelInitializer;
import io.netty.channel.ChannelOption;
import io.netty.channel.ChannelPipeline;
import io.netty.channel.EventLoopGroup;
import io.netty.channel.nio.NioEventLoopGroup;
import io.netty.channel.socket.SocketChannel;
import io.netty.channel.socket.nio.NioServerSocketChannel;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class PayServer implements Runnable
{
private static final Logger DLOG = LoggerFactory.getLogger(PayServer.class);
private final int port;
public PayServer(int port)
{
this.port = port;
}

/**
* 為ServerBootstrap綁定指定埠
*/
public void run()
{
// 用於接收發來的連接請求
final EventLoopGroup bossGroup = new NioEventLoopGroup();
// 用於處理boss接受並且注冊給worker的連接中的信息
final EventLoopGroup workerGroup = new NioEventLoopGroup();

try
{
// 配置伺服器
final ServerBootstrap bootstrap = new ServerBootstrap();
bootstrap.group(bossGroup, workerGroup);
bootstrap.channel(NioServerSocketChannel.class);
bootstrap.option(ChannelOption.SO_BACKLOG, 128);

// 通過NoDelay禁用Nagle,使消息立即發出去，不用等待到一定的數據量才發出去
bootstrap.option(ChannelOption.TCP_NODELAY, true);

// 保持長連接狀態
bootstrap.childOption(ChannelOption.SO_KEEPALIVE, true);

// CustomChannelInitializer是一個特殊的handler，用於方便的配置用戶自定義的handler實現
bootstrap.childHandler(new CustomChannelInitializer());

// 綁定並開始接受傳入的連接
final ChannelFuture future = bootstrap.bind(this.port).sync();
if (future.isSuccess())
{
PayServer.DLOG.info("Start the socket server {} success", this.port);
}
else
{
PayServer.DLOG.info("Start the socket server {} failure,System exit!", this.port);
throw new RuntimeException("Socket服務端啟動失敗");
}
// 等待伺服器套接字關閉
// 關閉伺服器
future.channel().closeFuture().sync();
}
catch (final InterruptedException e)
{
PayServer.DLOG.error("Close the socket server exception occurs,System exit!", e);
throw new RuntimeException("關閉Socket服務端失敗");
}
finally
{
// 關閉所有事件循環終止線程
bossGroup.shutdownGracefully();
workerGroup.shutdownGracefully();
}
}

/**
* 特殊的內部類
* <p>
* 是一個特殊的handler，用於方便的配置用戶自定義的handler實現
* @author xulonghui
*/
static class CustomChannelInitializer extends ChannelInitializer<SocketChannel>
{
@Override
protected void initChannel(SocketChannel ch) throws Exception
{
final ChannelPipeline p = ch.pipeline();
p.addLast(new PayMessageEncoder());
p.addLast(new PayMessageDecoder());
p.addLast(new PayServerHandler());
}
}
}

PayMessageEncoder.java
package com.miri.pay.scoket;
import io.netty.buffer.ByteBuf;
import io.netty.channel.ChannelHandlerContext;
import io.netty.handler.codec.MessageToByteEncoder;
import io.netty.util.CharsetUtil;
import com.miri.pay.model.CommonResponse;
import com.miri.pay.utils.jsonUtil;
/**
*消息編碼器
* <p>
* 編碼從服務端發送出的消息
*/
public class PayMessageEncoder extends MessageToByteEncoder<CommonResponse>
{

@Override
protected void encode(ChannelHandlerContext ctx, CommonResponse rsp, ByteBuf out) throws Exception
{
if (rsp != null)
{
final Object msgContent = rsp.getMsgContent();
// 消息ID,sequenceId和entityId三個加起來是12個長度
int msgLen = 12;
byte[] contentbs = new byte[] {};
if (msgContent != null)
{
final String content = JsonUtil.bean2json(msgContent);
contentbs = content.getBytes(CharsetUtil.UTF_8);
final int cl = contentbs.length;
msgLen += cl;
}
out.writeInt(msgLen);// 寫入當前消息的總長度
out.writeInt(rsp.getMsgId());// 寫入當前消息的消息ID
out.writeInt(rsp.getSequenceId());// 寫入當前消息的SequenceId
out.writeInt(rsp.getEntityId());// 寫入當前消息的EntityId

// 寫入消息主體內容
if (contentbs.length > 0)
{
out.writeBytes(contentbs);
}
}
}
}

PayMessageDecoder.java
package com.miri.pay.scoket;
import io.netty.buffer.ByteBuf;
import io.netty.channel.ChannelHandlerContext;
import io.netty.handler.codec.ByteToMessageDecoder;
import io.netty.util.CharsetUtil;
import java.util.List;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import com.miri.pay.constants.Constants;
import com.miri.pay.model.CommonRequest;
import com.miri.pay.utils.ByteUtil;
/**
* 消息解碼器
* <p>
* 解碼從客戶端請求的消息
*/
public class PayMessageDecoder extends ByteToMessageDecoder
{
private static final Logger DLOG = LoggerFactory.getLogger(PayMessageDecoder.class);
/**
* 表示頭長度的位元組數
*/
private static final int HEAD_LENGTH = 4;
/**
* 所有ID串所屬的位元組數
*/
private static final int ID_STR_LENGTH = 12;
/**
* 單個ID所屬的位元組數
*/
private static final int SINGLE_ID_LENGTH = 4;
@Override
protected void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception
{
int readable = in.readableBytes();
if (readable < PayMessageDecoder.HEAD_LENGTH)
{
return;
}
in.markReaderIndex(); // 我們標記一下當前的readIndex的位置
final int dataLength = in.readInt(); // 讀取傳送過來的消息的長度。ByteBuf 的readInt()方法會讓他的readIndex增加4
if (dataLength < 0)
{
// 我們讀到的消息體長度為0，這是不應該出現的情況，這里出現這情況，關閉連接。
ctx.close();
}

readable = in.readableBytes();
if (readable < dataLength)
{
// 讀到的消息體長度如果小於我們傳送過來的消息長度，則resetReaderIndex. 這個配合markReaderIndex使用的。把readIndex重置到mark的地方
in.resetReaderIndex();
return;
}
final byte[] body = new byte[dataLength];
in.readBytes(body);
// 判斷是否讀取到內容
final int length = body.length;
if (length == 0)
{
return;// 若未讀出任何內容，則忽略
}

out.add(this.byte2req(body));
}
/**
* 將讀取到的byte數據轉換為請求對象
* @param body
* @return
* @throws Exception
*/
private CommonRequest byte2req(byte[] body) throws Exception
{
final CommonRequest req = new CommonRequest(Constants.INVALID_MSGID);
final int length = body.length;

// 若內容數組的長度小於或等於12，則表示消息主體內容為空，直接返回一個無效的消息出去
if (length < PayMessageDecoder.ID_STR_LENGTH)
{
PayMessageDecoder.DLOG
.info("The client sends the message length is: {}, is invalid message, directly returns a msgId = {} request entity",
length, Constants.INVALID_MSGID);
return req;
}

// 獲取消息ID
final byte[] mbs = new byte[PayMessageDecoder.SINGLE_ID_LENGTH];
System.array(body, 0, mbs, 0, PayMessageDecoder.SINGLE_ID_LENGTH);
final int msgId = ByteUtil.byte4toint(mbs);
req.setMsgId(msgId);
// 獲取sequenceId
final byte[] sbs = new byte[PayMessageDecoder.SINGLE_ID_LENGTH];
System.array(body, 4, sbs, 0, PayMessageDecoder.SINGLE_ID_LENGTH);
final int sequenceId = ByteUtil.byte4toint(sbs);
req.setSequenceId(sequenceId);
// 獲取entityId
final byte[] ebs = new byte[PayMessageDecoder.SINGLE_ID_LENGTH];
System.array(body, 8, ebs, 0, PayMessageDecoder.SINGLE_ID_LENGTH);
final int entityId = ByteUtil.byte4toint(ebs);
req.setEntityId(entityId);

// 獲取消息主體內容
if (length > PayMessageDecoder.ID_STR_LENGTH)
{
final int contentLen = length - PayMessageDecoder.ID_STR_LENGTH;
final byte[] contentbs = new byte[contentLen];
System.array(body, 12, contentbs, 0, contentLen);
final String content = new String(contentbs, CharsetUtil.UTF_8);
req.setMsgContent(content);
}

return req;
}
}

PayServerHandler.java
package com.miri.pay.scoket;
import io.netty.channel.Channel;
import io.netty.channel.ChannelHandlerContext;
import io.netty.channel.ChannelInboundHandlerAdapter;
import io.netty.util.ReferenceCountUtil;
import java.util.HashMap;
import java.util.Map;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import com.miri.pay.MessageQueue;
import com.miri.pay.model.CommonRequest;
import com.miri.pay.model.PendingBean;
/**
* Socket服務端處理器
*/
public class PayServerHandler extends ChannelInboundHandlerAdapter
{
private static final Logger DLOG = LoggerFactory.getLogger(PayServerHandler.class);
/**
* 外部訂單號-頻道
*/
public static final Map<String, Channel> CHANNELS = new HashMap<String, Channel>();
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception
{
try
{
PayServerHandler.DLOG.info("Client send to msg is: {}", msg);
final CommonRequest request = (CommonRequest) msg;
final PendingBean bean = new PendingBean(ctx.channel(), request);
MessageQueue.offer(bean);
}
finally
{
ReferenceCountUtil.release(msg);
}
}

@Override
public void channelReadComplete(ChannelHandlerContext ctx) throws Exception
{
ctx.flush();
}
@Override
public void channelActive(ChannelHandlerContext ctx) throws Exception
{
super.channelActive(ctx);
final Channel channel = ctx.channel();
PayServerHandler.DLOG.info("Client active form {}", channel.remoteAddress());
}
@Override
public void channelInactive(ChannelHandlerContext ctx) throws Exception
{
super.channelInactive(ctx);
final Channel channel = ctx.channel();
PayServerHandler.DLOG.info("Client inactive form {}", channel.remoteAddress());
}
@Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception
{
PayServerHandler.DLOG.error("System exception", cause);
ctx.close();
}
}

Ⅳ socket 編程中 accept 函數返回

簡單的說就是通信的兩方的一種約定，用套接字中的相關函數來完成通信過程

應用層通過傳輸層進行數據通信時，TCP和UDP會遇到同時為多個應用程序進程提供並發服務的問題。多個TCP連接或多個應用程序進程可能需要通過同一個 TCP協議埠傳輸數據。為了區別不同的應用程序進程和連接，許多計算機操作系統為應用程序與TCP／IP協議交互提供了稱為套接字(Socket)的介面。

區分不同應用程序進程間的網路通信和連接，主要有3個參數：通信的目的IP地址、使用的傳輸層協議(TCP或UDP)和使用的埠號。Socket原意是 「插座」。通過將這3個參數結合起來，與一個「插座」Socket綁定，應用層就可以和傳輸層通過套接字介面，區分來自不同應用程序進程或網路連接的通信，實現數據傳輸的並發服務。

-- win API socket
本文所談到的Socket函數如果沒有特別說明，都是指的Windows Socket API。

一、WSAStartup函數
int WSAStartup(
WORD wVersionRequested,
LPWSADATA lpWSAData
);
使用Socket的程序在使用Socket之前必須調用WSAStartup函數。該函數的第一個參數指明程序請求使用的Socket版本，其中高位位元組指明副版本、低位位元組指明主版本；操作系統利用第二個參數返回請求的Socket的版本信息。當一個應用程序調用WSAStartup函數時，操作系統根據請求的Socket版本來搜索相應的Socket庫，然後綁定找到的Socket庫到該應用程序中。以後應用程序就可以調用所請求的 Socket庫中的其它Socket函數了。該函數執行成功後返回0。
例：假如一個程序要使用2.1版本的Socket,那麼程序代碼如下
wVersionRequested = MAKEWORD( 2, 1 );
err = WSAStartup( wVersionRequested, &wsaData );

二、WSACleanup函數
int WSACleanup (void);
應用程序在完成對請求的Socket庫的使用後，要調用WSACleanup函數來解除與Socket庫的綁定並且釋放Socket庫所佔用的系統資源。

三、socket函數
SOCKET socket(
int af,
int type,
int protocol
);
應用程序調用socket函數來創建一個能夠進行網路通信的套接字。第一個參數指定應用程序使用的通信協議的協議族，對於TCP/IP協議族，該參數置PF_INET;第二個參數指定要創建的套接字類型，流套接字類型為SOCK_STREAM、數據報套接字類型為SOCK_DGRAM；第三個參數指定應用程序所使用的通信協議。該函數如果調用成功就返回新創建的套接字的描述符，如果失敗就返回INVALID_SOCKET。套接字描述符是一個整數類型的值。每個進程的進程空間里都有一個套接字描述符表，該表中存放著套接字描述符和套接字數據結構的對應關系。該表中有一個欄位存放新創建的套接字的描述符，另一個欄位存放套接字數據結構的地址，因此根據套接字描述符就可以找到其對應的套接字數據結構。每個進程在自己的進程空間里都有一個套接字描述符表但是套接字數據結構都是在操作系統的內核緩沖里。下面是一個創建流套接字的例子：
struct protoent *ppe;
ppe=getprotobyname("tcp");
SOCKET ListenSocket=socket(PF_INET,SOCK_STREAM,ppe->p_proto);

四、closesocket函數
int closesocket(
SOCKET s
);
closesocket函數用來關閉一個描述符為s套接字。由於每個進程中都有一個套接字描述符表，表中的每個套接字描述符都對應了一個位於操作系統緩沖區中的套接字數據結構，因此有可能有幾個套接字描述符指向同一個套接字數據結構。套接字數據結構中專門有一個欄位存放該結構的被引用次數，即有多少個套接字描述符指向該結構。當調用closesocket函數時，操作系統先檢查套接字數據結構中的該欄位的值，如果為1，就表明只有一個套接字描述符指向它，因此操作系統就先把s在套接字描述符表中對應的那條表項清除，並且釋放s對應的套接字數據結構；如果該欄位大於1，那麼操作系統僅僅清除s在套接字描述符表中的對應表項，並且把s對應的套接字數據結構的引用次數減1。
closesocket函數如果執行成功就返回0，否則返回SOCKET_ERROR。

五、send函數
int send(
SOCKET s,
const char FAR *buf,
int len,
int flags
);
不論是客戶還是伺服器應用程序都用send函數來向TCP連接的另一端發送數據。客戶程序一般用send函數向伺服器發送請求，而伺服器則通常用 send函數來向客戶程序發送應答。該函數的第一個參數指定發送端套接字描述符；第二個參數指明一個存放應用程序要發送數據的緩沖區；第三個參數指明實際要發送的數據的位元組數；第四個參數一般置0。這里只描述同步Socket的send函數的執行流程。當調用該函數時，send先比較待發送數據的長度 len和套接字s的發送緩沖區的長度，如果len大於s的發送緩沖區的長度，該函數返回SOCKET_ERROR；如果len小於或者等於s的發送緩沖區的長度，那麼send先檢查協議是否正在發送s的發送緩沖中的數據，如果是就等待協議把數據發送完，如果協議還沒有開始發送s的發送緩沖中的數據或者s的發送緩沖中沒有數據，那麼send就比較s的發送緩沖區的剩餘空間和len，如果len大於剩餘空間大小send就一直等待協議把s的發送緩沖中的數據發送完，如果len小於剩餘空間大小send就僅僅把buf中的數據到剩餘空間里（注意並不是send把s的發送緩沖中的數據傳到連接的另一端的，而是協議傳的，send僅僅是把buf中的數據到s的發送緩沖區的剩餘空間里）。如果send函數數據成功，就返回實際的位元組數，如果send在數據時出現錯誤，那麼send就返回SOCKET_ERROR；如果send在等待協議傳送數據時網路斷開的話，那麼send 函數也返回SOCKET_ERROR。要注意send函數把buf中的數據成功到s的發送緩沖的剩餘空間里後它就返回了，但是此時這些數據並不一定馬上被傳到連接的另一端。如果協議在後續的傳送過程中出現網路錯誤的話，那麼下一個Socket函數就會返回SOCKET_ERROR。（每一個除 send外的Socket函數在執行的最開始總要先等待套接字的發送緩沖中的數據被協議傳送完畢才能繼續，如果在等待時出現網路錯誤，那麼該Socket 函數就返回SOCKET_ERROR）
注意：在Unix系統下，如果send在等待協議傳送數據時網路斷開的話，調用send的進程會接收到一個SIGPIPE信號，進程對該信號的默認處理是進程終止。

六、recv函數
int recv(
SOCKET s,
char FAR *buf,
int len,
int flags
);
不論是客戶還是伺服器應用程序都用recv函數從TCP連接的另一端接收數據。該函數的第一個參數指定接收端套接字描述符；第二個參數指明一個緩沖區，該緩沖區用來存放recv函數接收到的數據；第三個參數指明buf的長度；第四個參數一般置0。這里只描述同步Socket的recv函數的執行流程。當應用程序調用recv函數時，recv先等待s的發送緩沖中的數據被協議傳送完畢，如果協議在傳送s的發送緩沖中的數據時出現網路錯誤，那麼 recv函數返回SOCKET_ERROR，如果s的發送緩沖中沒有數據或者數據被協議成功發送完畢後，recv先檢查套接字s的接收緩沖區，如果s接收緩沖區中沒有數據或者協議正在接收數據，那麼recv就一直等待，只到協議把數據接收完畢。當協議把數據接收完畢，recv函數就把s的接收緩沖中的數據 到buf中（注意協議接收到的數據可能大於buf的長度，所以在這種情況下要調用幾次recv函數才能把s的接收緩沖中的數據完。 recv函數僅僅是數據，真正的接收數據是協議來完成的），recv函數返回其實際的位元組數。如果recv在時出錯，那麼它返回 SOCKET_ERROR；如果recv函數在等待協議接收數據時網路中斷了，那麼它返回0。
注意：在Unix系統下，如果recv函數在等待協議接收數據時網路斷開了，那麼調用recv的進程會接收到一個SIGPIPE信號，進程對該信號的默認處理是進程終止。

七、bind函數
int bind(
SOCKET s,
const struct sockaddr FAR *name,
int namelen
);
當創建了一個Socket以後，套接字數據結構中有一個默認的IP地址和默認的埠號。一個服務程序必須調用bind函數來給其綁定一個IP地址和一個特定的埠號。客戶程序一般不必調用bind函數來為其Socket綁定IP地址和斷口號。該函數的第一個參數指定待綁定的Socket描述符；第二個參數指定一個sockaddr結構，該結構是這樣定義的：
struct sockaddr {
u_short sa_family;
char sa_data[14];
};
sa_family指定地址族，對於TCP/IP協議族的套接字，給其置AF_INET。當對TCP/IP協議族的套接字進行綁定時，我們通常使用另一個地址結構：
struct sockaddr_in {
short sin_family;
u_short sin_port;
struct in_addr sin_addr;
char sin_zero[8];
};
其中sin_family置AF_INET；sin_port指明埠號；sin_addr結構體中只有一個唯一的欄位s_addr，表示IP地址，該欄位是一個整數，一般用函數inet_addr（）把字元串形式的IP地址轉換成unsigned long型的整數值後再置給s_addr。有的伺服器是多宿主機，至少有兩個網卡，那麼運行在這樣的伺服器上的服務程序在為其Socket綁定IP地址時可以把htonl(INADDR_ANY)置給s_addr，這樣做的好處是不論哪個網段上的客戶程序都能與該服務程序通信；如果只給運行在多宿主機上的服務程序的Socket綁定一個固定的IP地址，那麼就只有與該IP地址處於同一個網段上的客戶程序才能與該服務程序通信。我們用0來填充 sin_zero數組，目的是讓sockaddr_in結構的大小與sockaddr結構的大小一致。下面是一個bind函數調用的例子：
struct sockaddr_in saddr；
saddr.sin_family = AF_INET;
saddr.sin_port = htons(8888);
saddr.sin_addr.s_addr = htonl(INADDR_ANY);
bind(ListenSocket,(struct sockaddr *)&saddr,sizeof(saddr))；

八、listen函數
int listen( SOCKET s, int backlog );
服務程序可以調用listen函數使其流套接字s處於監聽狀態。處於監聽狀態的流套接字s將維護一個客戶連接請求隊列，該隊列最多容納backlog個客戶連接請求。假如該函數執行成功，則返回0；如果執行失敗，則返回SOCKET_ERROR。

九、accept函數
SOCKET accept(
SOCKET s,
struct sockaddr FAR *addr,
int FAR *addrlen
);
服務程序調用accept函數從處於監聽狀態的流套接字s的客戶連接請求隊列中取出排在最前的一個客戶請求，並且創建一個新的套接字來與客戶套接字創建連接通道，如果連接成功，就返回新創建的套接字的描述符，以後與客戶套接字交換數據的是新創建的套接字；如果失敗就返回 INVALID_SOCKET。該函數的第一個參數指定處於監聽狀態的流套接字；操作系統利用第二個參數來返回新創建的套接字的地址結構；操作系統利用第三個參數來返回新創建的套接字的地址結構的長度。下面是一個調用accept的例子：
struct sockaddr_in ServerSocketAddr;
int addrlen;
addrlen=sizeof(ServerSocketAddr);
ServerSocket=accept(ListenSocket,(struct sockaddr *)&ServerSocketAddr,&addrlen);

十、connect函數
int connect(
SOCKET s,
const struct sockaddr FAR *name,
int namelen
);
客戶程序調用connect函數來使客戶Socket s與監聽於name所指定的計算機的特定埠上的服務Socket進行連接。如果連接成功，connect返回0；如果失敗則返回SOCKET_ERROR。下面是一個例子：
struct sockaddr_in daddr;
memset((void *)&daddr,0,sizeof(daddr));
daddr.sin_family=AF_INET;
daddr.sin_port=htons(8888);
daddr.sin_addr.s_addr=inet_addr("133.197.22.4");
connect(ClientSocket,(struct sockaddr *)&daddr,sizeof(daddr))；

Ⅳ socket是什麼呀

套接字(Socket)，就是對網路中不同主機上的應用進程之間進行雙向通信的端點的抽象。

一個套接字就是網路上進程通信的一端，提供了應用層進程利用網路協議交換數據的機制。從所處的地位來講，套接字上聯應用進程，下聯網路協議棧，是應用程序通過網路協議進行通信的介面，是應用程序與網路協議根進行交互的介面。

套接字是通信的基石，是支持TCP/IP協議的路通信的基本操作單元。

可以將套接字看作不同主機間的進程進行雙間通信的端點，它構成了單個主機內及整個網路間的編程界面。套接字存在於通信域中，通信域是為了處理一般的線程通過套接字通信而引進的一種抽象概念。

套接字通常和同一個域中的套接字交換數據(數據交換也可能穿越域的界限，但這時一定要執行某種解釋程序)，各種進程使用這個相同的域互相之間用Internet協議簇來進行通信。

Socket(套接字)可以看成是兩個網路應用程序進行通信時，各自通信連接中的端點，這是一個邏輯上的概念。它是網路環境中進程間通信的API(應用程序編程介面)，也是可以被命名和定址的通信端點，使用中的每一個套接字都有其類型和一個與之相連進程。

通信時其中一個網路應用程序將要傳輸的一段信息寫入它所在主機的 Socket中，該 Socket通過與網路介面卡(NIC)相連的傳輸介質將這段信息送到另外一台主機的 Socket中，使對方能夠接收到這段信息。

Socket是由IP地址和埠結合的，提供向應用層進程傳送數據包的機制。

類型

1、數據報套接字

無連接套接字，使用用戶數據報協議(UDP)。在數據報套接字上發送或接收的每個數據包都單獨定址和路由。數據報套接字不能保證順序和可靠性，因此從一台機器或進程發送到另一台機器或進程的多個數據包可能以任何順序到達或可能根本不到達。在數據報套接字上發送廣播可能需要特殊配置。

為了接收廣播數據包，數據報套接字不應該綁定到特定地址，盡管在某些實現中，當數據報套接字綁定到特定地址時也可能接收廣播數據包。

2、流套接字

面向連接的套接字，使用傳輸控制協議(TCP)、流控制傳輸協議(SCTP) 或數據報擁塞控制協議(DCCP)。流套接字提供了無記錄邊界的有序且獨特的無錯誤數據流，並具有用於創建和銷毀連接以及報告錯誤的明確定義的機制。

流套接字以帶外功能可靠地、有序地傳輸數據。在 Internet 上，流套接字通常使用 TCP 實現，以便應用程序可以使用 TCP/IP 協議在任何網路上運行。

3、原始套接字

允許直接發送和接收 IP 數據包，無需任何特定於協議的傳輸層格式。對於其他類型的套接字，根據選擇的傳輸層協議（例如 TCP、UDP）自動封裝有效載荷，並且套接字用戶不知道與有效載荷一起廣播的協議頭的存在。從原始套接字讀取時，通常包含標頭。

從原始套接字傳輸數據包時，自動添加標頭是可選的。

大多數套接字應用程序編程介面(API)，例如基於Berkeley 套接字的那些，支持原始套接字。Windows XP於 2001 年發布，在Winsock介面中實現了原始套接字支持，但三年後，微軟出於安全考慮限制了 Winsock 的原始套接字支持。

原始套接字用於與安全相關的應用程序，如Nmap。原始套接字的一個用例是在用戶空間中實現新的傳輸層協議。

原始套接字通常在網路設備中可用，用於路由協議，例如Internet 組管理協議(IGMP) 和開放最短路徑優先(OSPF)，以及用於Internet 控制消息協議(ICMP) 等事情，由ping 實用程序。

以上內容參考網路-套接字