Использование сокетов для работы с UDP. С некоторой аналогией
Последнее обновление: 31.10.2015
Протокол UDP не требует установки постоянного подключения, и, возможно, многим покажется легче работать с UDP, чем с TCP. Большинство принципов при работе с UDP те же, что и с TCP.
Вначале создается сокет:
Socket socket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
Если сокет должен получать сообщения, то надо привязать его к локальному адресу и одному из портов с помощью метода Bind:
IPEndPoint localIP = new IPEndPoint(IPAddress.Parse("127.0.0.1"), 5555); socket.Bind(localIP);
После этого можно отправлять и получать сообщения. Для получения сообщений используется метод ReceiveFrom() :
Byte data = new byte; // буфер для получаемых данных //адрес, с которого пришли данные EndPoint remoteIp = new IPEndPoint(IPAddress.Any, 0); int bytes = socket.ReceiveFrom(data, ref remoteIp);
В качестве параметра в метод передается массив байтов, в который надо считать данные, и удаленная точка, с которой приходят эти данные. Метод возвращает количество считанных байтов.
Для отправки данных используется метод SendTo() :
String message = Console.ReadLine(); byte data = Encoding.Unicode.GetBytes(message); EndPoint remotePoint = new IPEndPoint(IPAddress.Parse("127.0.0.1"), remotePort); listeningSocket.SendTo(data, remotePoint);
В метод передается массив отправляемых данных, а также адрес, по которому эти данные надо отправить.
Создадим программу UDP-клиента:
Using System; using System.Text; using System.Threading.Tasks; using System.Net; using System.Net.Sockets; namespace SocketUdpClient { class Program { static int localPort; // порт приема сообщений static int remotePort; // порт для отправки сообщений static Socket listeningSocket; static void Main(string args) { Console.Write("Введите порт для приема сообщений: "); localPort = Int32.Parse(Console.ReadLine()); Console.Write("Введите порт для отправки сообщений: "); remotePort = Int32.Parse(Console.ReadLine()); Console.WriteLine("Для отправки сообщений введите сообщение и нажмите Enter"); Console.WriteLine(); try { listeningSocket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp); Task listeningTask = new Task(Listen); listeningTask.Start(); // отправка сообщений на разные порты while (true) { string message = Console.ReadLine(); byte data = Encoding.Unicode.GetBytes(message); EndPoint remotePoint = new IPEndPoint(IPAddress.Parse("127.0.0.1"), remotePort); listeningSocket.SendTo(data, remotePoint); } } catch (Exception ex) { Console.WriteLine(ex.Message); } finally { Close(); } } // поток для приема подключений private static void Listen() { try { //Прослушиваем по адресу IPEndPoint localIP = new IPEndPoint(IPAddress.Parse("127.0.0.1"), localPort); listeningSocket.Bind(localIP); while (true) { // получаем сообщение StringBuilder builder = new StringBuilder(); int bytes = 0; // количество полученных байтов byte data = new byte; // буфер для получаемых данных //адрес, с которого пришли данные EndPoint remoteIp = new IPEndPoint(IPAddress.Any, 0); do { bytes = listeningSocket.ReceiveFrom(data, ref remoteIp); builder.Append(Encoding.Unicode.GetString(data, 0, bytes)); } while (listeningSocket.Available > 0); // получаем данные о подключении IPEndPoint remoteFullIp = remoteIp as IPEndPoint; // выводим сообщение Console.WriteLine("{0}:{1} - {2}", remoteFullIp.Address.ToString(), remoteFullIp.Port, builder.ToString()); } } catch (Exception ex) { Console.WriteLine(ex.Message); } finally { Close(); } } // закрытие сокета private static void Close() { if (listeningSocket != null) { listeningSocket.Shutdown(SocketShutdown.Both); listeningSocket.Close(); listeningSocket = null; } } } }
Вначале пользователь вводит порты для приема данных и для отправки. Предполагается, что два приложения клиента, которые будут между собой взаимодействовать, запущены на одной локальной машине. Если адреса клиентов различаются, то можно предусмотреть и ввода адреса для отправки данных.
После ввода портов запускается задача на прослушивание входящих сообщений. В отличие от tcp-сервера здесь не надо вызывать методы Listen и Accept. В бесконечном цикле мы напрямую можем получить получение данные с помощью метода ReceiveFrom() , который блокирует вызывающий поток, пока не придет очередная порция данных.
Этот метод возвращает через ref-параметр удаленную точку, с которой получены данные:
IPEndPoint remoteFullIp = remoteIp as IPEndPoint;
То есть, не смотря на то, что в данном случае прием и отправка сообщений разграничены и текущий клиент отправляет данные только на введенный вначале порт, но мы вполне можем добавить возможность ответа на сообщения, используя данные полученной удаленной точки (адрес и порт).
В главном потоке происходит отправка сообщений с помощью метода SendTo()
Таким образом, приложение сразу осуществляет функции и сервера, и клиента.
Теперь запустим две копии приложения и введем разные данные для портов. Первый клиент:
Введите порт для приема сообщений: 4004 Введите порт для отправки сообщений: 4005 Для отправки сообщений введите сообщение и нажмите Enter 127.0.0.1:4005 - привет порт 4004 добрый день, порт 4005 чудная погодка
Второй клиент:
Введите порт для приема сообщений: 4005 Введите порт для отправки сообщений: 4004 Для отправки сообщений введите сообщение и нажмите Enter привет порт 4004 127.0.0.1:4004 - добрый день, порт 4005 127.0.0.1:4004 - чудная погодка
Пора применить эрланг по его прямому назначению -- для реализации сетевого сервиса. Чаще всего такие сервисы делают на базе веб-сервера, поверх протокола HTTP . Но мы возьмем уровень ниже -- TCP и UDP сокеты.
Я полагаю, вы уже знаете, как устроена сеть, что такое Internet Protocol , User Datagram Protocol и Transmission Control Protocol . Эта тема большинству программистов известна. Но если вы почему-то ее упустили, то придется сперва наверстать упущенное, и потом вернуться к этому уроку.
UDP сокет
Вспомним в общих чертах, что такое UDP:
- протокол передачи коротких сообщений (Datagram);
- быстрая доставка;
- без постоянного соединения между клиентом и сервером, без состояния;
- доставка сообщения и очередность доставки не гарантируется.
Для работы с UDP используется модуль gen_udp .
Давайте запустим две ноды и наладим общение между ними.
На 1-й ноде откроем UDP на порту 2000:
1> {ok, Socket} = gen_udp:open(2000, ). {ok,#Port<0.587>}
Вызываем gen_udp:open/2 , передаем номер порта и список опций. Список всех возможных опций довольно большой, но нас интересуют две из них:
binary -- сокет открыт в бинарном режиме. Как вариант, сокет можно открыть в текстовом режиме, указав опцию list . Разница в том, как мы интерпретируем данные, полученные из сокета -- как поток байт, или как текст.
{active, true} -- сокет открыт в активном режиме, значит данные, приходящие в сокет, будут посылаться в виде сообщений в почтовый ящик потока, владельца сокета. Подробнее об этом ниже.
На 2-й ноде откроем UDP на порту 2001:
1> {ok, Socket} = gen_udp:open(2001, ). {ok,#Port<0.587>}
И пошлем сообщение с 1-й ноды на 2-ю:
2> gen_udp:send(Socket, {127,0,0,1}, 2001, <<"Hello from 2000">>). ok
Вызываем gen_udp:send/4 , передаем сокет, адрес и порт получателя, и само сообщение.
Адрес может быть доменным именем в виде строки или атома, или адресом IPv4 в виде кортежа из 4-х чисел, или адресом IPv6 в виде кортежа из 8 чисел.
На 2-й ноде убедимся, что сообщение пришло:
2> <0.587>,{127,0,0,1},2000,<<"Hello from 2000">>} ok
Сообщение приходит в виде кортежа {udp, Socket, SenderAddress, SenderPort, Packet} .
Пошлем сообщение с 2-й ноды на 1-ю:
3> gen_udp:send(Socket, {127,0,0,1}, 2000, <<"Hello from 2001">>). ok
На 1-й ноде убедимся, что сообщение пришло:
3> flush(). Shell got {udp,#Port<0.587>,{127,0,0,1},2001,<<"Hello from 2001">>} ok
Как видим, тут все просто.
Активный и пассивный режим сокета
И gen_udp , и gen_tcp , оба имеют одну важную настройку: режим работы с входящими данными. Это может быть либо активный режим {active, true} , либо пассивный режим {active, false} .
В активном режиме поток получает входящие пакеты в виде сообщений в своем почтовом ящике. И их можно получить и обработать вызовом receive, как любые другие сообщения.
Для udp сокета это сообщения вида:
{udp, Socket, SenderAddress, SenderPort, Packet}
мы их уже видели:
{udp,#Port<0.587>,{127,0,0,1},2001,<<"Hello from 2001">>}
Для tcp сокета аналогичные сообщения:
{tcp, Socket, Packet}
Активный режим прост в использовании, но опасен тем, что клиент может переполнить очередь сообщений потока, исчерпать память и обрушить ноду. Поэтому рекомендуется пассивный режим.
В пассивном режиме данные нужно забрать самому вызовами gen_udp:recv/3 и gen_tcp:recv/3 :
Gen_udp:recv(Socket, Length, Timeout) -> {ok, {Address, Port, Packet}} | {error, Reason} gen_tcp:recv(Socket, Length, Timeout) -> {ok, Packet} | {error, Reason}
Здесь мы указываем, сколько байт данных хотим прочитать из сокета. Если там есть эти данные, то мы получаем их сразу. Если нет, то вызов блокируется, пока не придет достаточное количество данных. Можно указать Timeout, чтобы не блокировать поток надолго.
Однако, gen_udp:recv игнорирует аргумент Length, и возвращает все данные, которые есть в сокете. Или блокируется и ждет каких-нибудь данных, если в сокете ничего нет. Непонятно, зачем вообще аргумент Length присутствует в АПИ.
Для gen_tcp:recv аргумент Length работает как надо. Если только не указана опция {packet, Size} , о которой речь пойдет ниже.
Еще есть вариант {active, once} . В этом случае сокет запускается в активном режиме, получает первый пакет данных как сообщение, и сразу переключается в пассивный режим.
TCP сокет
Вспомним в общих чертах, что такое TCP:
- надежный протокол передачи данных, гарантирует доставку сообщения и очередность доставки;
- постоянное соединение клиента и сервера, имеет состояние;
- дополнительные накладные расходы на установку и закрытие соединения и на передачу данных.
Надо заметить, что долго держать постоянные соединения с многими тысячами клиентов накладно. Все соединения должны работать независимо друг от друга, а это значит -- в разных потоках. Для многих языков программирования (но не для эрланг) это серьезная проблема.
Именно поэтому так популярен протокол HTTP, который хоть и работает поверх TCP сокета, но подразумевает короткое время взаимодействия. Это позволяет относительно небольшим числом потоков (десятки-сотни) обслуживать значительно большее число клиентов (тысячи, десятки тысяч).
В некоторых случаях остается необходимость иметь долгоживущие постоянные соединения между клиентом и сервером. Например, для чатов или для многопользовательских игр. И здесь эрланг имеет мало конкурентов.
Для работы с TCP используется модуль gen_tcp .
Работать с TCP сокетом сложнее, чем с UDP. У нас появляются роли клиента и сервера, требующие разной реализации. Рассмотрим вариант реализации сервера.
Module(server). -export(). start() -> start(1234). start(Port) -> spawn(?MODULE, server, ), ok. server(Port) -> io:format("start server at port ~p~n", ), {ok, ListenSocket} = gen_tcp:listen(Port, ), ) || Id <- lists:seq(1, 5)], timer:sleep(infinity), ok. accept(Id, ListenSocket) -> io:format("Socket #~p wait for client~n", ), {ok, _Socket} = gen_tcp:accept(ListenSocket), io:format("Socket #~p, session started~n", ), handle_connection(Id, ListenSocket). handle_connection(Id, ListenSocket) -> receive {tcp, Socket, Msg} -> io:format("Socket #~p got message: ~p~n", ), gen_tcp:send(Socket, Msg), handle_connection(Id, ListenSocket); {tcp_closed, _Socket} ->
Есть два вида сокета: Listen Socket и Accept Socket . Listen Socket один, он принимает все запросы на соединение. Accept Socket нужно много, по одному для каждого соединения. Поток, в котором создается сокет, становится владельцем сокета. Если поток-владелец завершается, то сокет автоматически закрывается. Поэтому для каждого сокета мы создаем отдельный поток.
Listen Socket должен работать всегда, а для этого его поток-владелец не должен завершаться. Поэтому в server/1 мы добавили вызов timer:sleep(infinity) . Это заблокирует поток и не даст ему завершиться. Такая реализация, конечно, учебная. По хорошему нужно предусмотреть возможность корректно остановить сервер, а здесь этого нет.
Accept Socket и поток для него можно было бы создавать динамически, по мере появления клиентов. В начале можно создать один такой поток, вызвать в нем gen_tcp:accept/1 и ждать клиента. Этот вызов является блокирующим. Он завершается, когда появляется клиент. Дальше можно обслуживать текущего клиента в этом потоке, и создать новый поток, ожидающий нового клиента.
Но здесь у нас другая реализация. Мы заранее создаем пул из нескольких потоков, и все они ждут клиентов. После завершения работы с одним клиентом сокет не закрывается, а ждет нового. Таким образом, вместо того, чтобы постоянно открывать новые сокеты и закрывать старые, мы используем пул долгоживущих сокетов.
Это эффективнее при большом количестве клиентов. Во-первых, из-за того, что мы быстрее принимаем соединения. Во-вторых, из-за того, что мы более аккуратно распоряжаемся сокетами как системным ресурсом.
Потоки принадлежат эрланговской ноде, и мы можем создавать их сколько угодно. Но сокеты принадлежат операционной системе. Их количество лимитировано, хотя и довольно большое. (Речь идет о лимите на количество файловых дескрипторов, которое операционная система позволяет открыть пользовательскому процессу, обычно это 2 10 - 2 16).
Размер пула у нас игрушечный -- 5 пар поток-сокет. Реально нужен пул из нескольких сотен таких пар. Хорошо бы еще иметь возможность увеличивать и уменьшать этот пул в рантайме, чтобы подстраиваться под текущую нагрузку.
Текущая сессия с клиентом обрабатывается в функции handle_connection/2 . Видно, что сокет работает в активном режиме, и поток получает сообщения вида {tcp, Socket, Msg} , где Msg -- это бинарные данные, пришедшие от клиента. Эти данные мы отравляет обратно клиенту, то есть, реализуем банальный эхо-сервис:)
Когда клиент закрывает соединение, поток получает сообщение {tcp_closed, _Socket} , возвращается обратно в accept/2 и ждет следующего клиента.
Вот как выглядит работа такого сервера с двумя telnet-клиентами:
$ telnet localhost 1234 Trying 127.0.0.1... Connected to localhost. Escape character is "^]". hello from client 1 hello from client 1 some message from client 1 some message from client 1 new message from client 1 new message from client 1 client 1 is going to close connection client 1 is going to close connection ^] telnet> quit Connection closed.
$ telnet localhost 1234 Trying 127.0.0.1... Connected to localhost. Escape character is "^]". hello from client 2 hello from client 2 message from client 2 message from client 2 client 2 is still active client 2 is still active but client 2 is still active but client 2 is still active and now client 2 is going to close connection and now client 2 is going to close connection ^] telnet> quit Connection closed.
2> server:start(). start server at port 1234 ok Socket #1 wait for client Socket #2 wait for client Socket #3 wait for client Socket #4 wait for client Socket #5 wait for client Socket #1, session started Socket #1 got message: <<"hello from client 1\r\n">> Socket #1 got message: <<"some message from client 1\r\n">> Socket #2, session started Socket #2 got message: <<"hello from client 2\r\n">> Socket #2 got message: <<"message from client 2\r\n">> Socket #1 got message: <<"new message from client 1\r\n">> Socket #2 got message: <<"client 2 is still active\r\n">> Socket #1 got message: <<"client 1 is going to close connection\r\n">> Socket #1, session closed Socket #1 wait for client Socket #2 got message: <<"but client 2 is still active\r\n">> Socket #2 got message: <<"and now client 2 is going to close connection\r\n">> Socket #2, session closed Socket #2 wait for client
Сервер в пассивном режиме
Это все хорошо, но хороший сервер должен работать в пассивном режиме. То есть, он должен получать данные от клиента не в виде сообщений в почтовый ящик, а вызовом gen_tcp:recv/2,3 .
Нюанс в том, что тут нужно указать, сколько данных мы хотим прочитать. А откуда сервер может знать, сколько данных ему прислал клиент? Ну, видимо, клиент сам должен сказать, сколько данных он собирается прислать. Для этого клиент сперва посылает небольшой служебный пакет, в котором указывает размер своих данных, и затем посылает сами данные.
Теперь нужно решить, сколько байт должен занимать этот служебный пакет. Если это будет 1 байт, то в него нельзя упаковать число больше 255. В 2 байта можно упаковать число 65535, в 4 байта 4294967295. 1 байт, очевидно, мало. Вполне вероятно, что клиенту будет нужно послать данных больше, чем 255 байт. Заголовок в 2 байта вполне подходит. Заголовок в 4 байта иногда бывает нужен.
Итак, клиент посылает служебный пакет размером в 2 байта, где указано, сколько данных последуют за ним, а затем сами эти данные:
Msg = <<"Hello">>,
Size = byte_size(Msg),
Header = <
Полный код клиента:
Module(client2).
-export().
start() ->
start("localhost", 1234).
start(Host, Port) ->
spawn(?MODULE, client, ).
send(Pid, Msg) ->
Pid ! {send, Msg},
ok.
stop(Pid) ->
Pid ! stop,
ok.
client(Host, Port) ->
io:format("Client ~p connects to ~p:~p~n", ),
{ok, Socket} = gen_tcp:connect(Host, Port, ),
loop(Socket).
loop(Socket) ->
receive
{send, Msg} ->
io:format("Client ~p send ~p~n", ),
Size = byte_size(Msg),
Header = <
Сервер сперва читает 2 байта, определяет размер данных и затем читает все данные:
{ok, Header} = gen_tcp:recv(Socket, 2),
<
В коде сервера функции start/0 и start/1 не изменились, остальное немного поменялось:
Server(Port) ->
io:format("start server at port ~p~n", ),
{ok, ListenSocket} = gen_tcp:listen(Port, ),
) || Id <- lists:seq(1, 5)],
timer:sleep(infinity),
ok.
accept(Id, ListenSocket) ->
io:format("Socket #~p wait for client~n", ),
{ok, Socket} = gen_tcp:accept(ListenSocket),
io:format("Socket #~p, session started~n", ),
handle_connection(Id, ListenSocket, Socket).
handle_connection(Id, ListenSocket, Socket) ->
case gen_tcp:recv(Socket, 2) of
{ok, Header} -> <
Пример сессии со стороны клиента:
2> Pid = client2:start(). Client <0.40.0> connects to "localhost":1234 <0.40.0> 3> client2:send(Pid, <<"Hello">>). Client <0.40.0> send <<"Hello">> ok Client <0.40.0> got message: <<"Hello">> 4> client2:send(Pid, <<"Hello again">>). Client <0.40.0> send <<"Hello again">> ok Client <0.40.0> got message: <<"Hello again">> 5> client2:stop(Pid). Client <0.40.0> closes connection and stops ok
И со стороны сервера:
2> server2:start(). start server at port 1234 ok Socket #1 wait for client Socket #2 wait for client Socket #3 wait for client Socket #4 wait for client Socket #5 wait for client Socket #1, session started Socket #1 got message: <<"Hello">> Socket #1 got message: <<"Hello again">> Socket #1, session closed Socket #1 wait for client
Все это хорошо, но на самом деле нет необходимости вручную разбираться с заголовочным пакетом. Это уже реализовано в gen_tcp . Нужно указать размер служебного пакета в настройках при открытии сокета на стороне клиента:
{ok, Socket} = gen_tcp:connect(Host, Port, ),
и на стороне сервера:
{ok, ListenSocket} = gen_tcp:listen(Port, ),
и необходимость самому формировать и разбирать эти заголовки пропадает.
На стороне клиента упрощается отправка:
Gen_tcp:send(Socket, Msg),
и на стороне сервера упрощается получение:
Handle_connection(Id, ListenSocket, Socket) -> case gen_tcp:recv(Socket, 0) of {ok, Msg} -> io:format("Socket #~p got message: ~p~n", ), gen_tcp:send(Socket, Msg), handle_connection(Id, ListenSocket, Socket); {error, closed} -> io:format("Socket #~p, session closed ~n", ), accept(Id, ListenSocket) end.
Теперь при вызове gen_tcp:recv/2 мы указываем Length = 0. gen_tcp сам знает, сколько байт нужно прочитать из сокета.
Работа с текстовыми протоколами
Кроме варианта со служебным заголовком, есть и другой подход. Можно читать из сокета по одному байту, пока не встретится специальный байт, символизирующий конец пакета. Это может быть нулевой байт, или символ перевода строки.
Такой вариант характерен для текстовых протоколов (SMTP, POP3, FTP).
Писать свою реализацию чтения из сокета нет необходимости, все уже реализовано в gen_tcp . Нужно только указать в настройках сокета вместо {packet, 2} опцию {packet, line} .
{ok, ListenSocket} = gen_tcp:listen(Port, ),
В остальном код сервера остается без изменений. Но теперь мы можем опять вернуться к telnet-клиенту.
$ telnet localhost 1234 Trying 127.0.0.1... Connected to localhost. Escape character is "^]". hello hello hello again hello again ^] telnet> quit Connection closed.
TCP-сервер, текстовый протокол и telnet-клиент нам понадобятся в курсовой работе.
Отсюда и "заточка" этого протокола под работу с отдельными документами, преимущественно текстовыми. HTTP в своей работе использует возможности TCP/IP, поэтому рассмотрим возможности, предоставляемые java для работы с последним.
В джаве для этого существует специальный пакет "java.net", содержащий класс java.net.Socket. Socket в переводе означает "гнездо", название это было дано по аналогии с гнёздами на аппаратуре, теми самыми, куда подключают штепсели. Соответственно этой аналогии, можно связать два "гнезда", и передавать между ними данные. Каждое гнездо принадлежит определённому хосту (Host - хозяин, держатель). Каждый хост имеет уникальный IP (Internet Packet) адрес. На данный момент интернет работает по протоколу IPv4, где IP адрес записывается 4 числами от 0 до 255 - например, 127.0.0.1 (подробнее о распределении IP адресов тут - RFC 790 , RFC 1918 , RFC 2365 , о версии IPv6 читайте тут - RFC 2373)
Гнёзда монтируются на порт хоста (port). Порт обозначается числом от 0 до 65535 и логически обозначает место, куда можно пристыковать (bind) сокет. Если порт на этом хосте уже занят каким-то сокетом, то ещё один сокет туда пристыковать уже не получится. Таким образом, после того, как сокет установлен, он имеет вполне определённый адрес, символически записывающийся так :, к примеру - 127.0.0.1:8888 (означает, что сокет занимает порт 8888 на хосте 127.0.0.1)
Для того, чтобы облегчить жизнь, чтобы не использовать неудобозапоминаемый IP адрес, была придумана система DNS (DNS - Domain Name Service). Цель этой системы - сопоставлять IP адресам символьные имена. К примеру, адресу "127.0.0.1" в большинстве компьютеров сопоставленно имя "localhost" (в просторечье - "локалхост").
Локалхост, фактически, означает сам компьютер, на котором выполняется программа, он же - локальный компьютер. Вся работа с локалхостом не требует выхода в сеть и связи с какими-либо другими хостами.
Клиентский сокет
Итак, вернёмся к классу java.net.Socket Наиболее удобно инициализировать его следующим образом:
Public Socket(String host, int port) throws UnknownHostException, IOException В строковой константе host можно указать как IP адрес сервера, так и его DNS имя. При этом программа автоматически выберет свободный порт на локальном компьютере и "привинтит" туда ваш сокет, после чего будет предпринята попытка связаться с другим сокетом, адрес которого указан в параметрах инициализации. При этом могут возникнуть два вида исключений: неизвестный адрес хоста - когда в сети нет компьютера с таким именем или ошибка отсутствия связи с этим сокетом.
Так же полезно знать функцию
Public void setSoTimeout(int timeout) throws SocketException Эта функция устанавливает время ожидания (timeout) для работы с сокетом. Если в течение этого времени никаких действий с сокетом не произведено (имеется ввиду получение и отправка данных), то он самоликвидируется. Время задаётся в секундах, при установке timeout равным 0 сокет становится "вечным".
Для некоторых сетей изменение timeout невозможно или установлено в определённых интервалах (к примеру от 20 до 100 секунд). При попытке установить недопустимый timeout, будет выдано соответственное исключение.
Программа, которая открывает сокет этого типа, будет считаться клиентом, а программа-владелец сокета, к которому вы пытаетесь подключиться, далее будет называться сервером. Фактически, по аналогии гнездо-штепсель, программа-сервер - это и будет гнездо, а клиент как раз является тем самым штепселем.
Сокет сервера
Как установить соединение от клиента к серверу я только что описал, теперь - как сделать сокет, который будет обслуживать сервер. Для этого в джава существует следующий класс: java.net.ServerSocket Наиболее удобным инициализатором для него является следующий:
Public ServerSocket(int port, int backlog, InetAddress bindAddr) throws IOException Как видно, в качестве третьего параметра используется объект ещё одного класса - java.net.InetAddress Этот класс обеспечивает работу с DNS и IP именами, по этому вышеприведённый инициализатор в программах можно использовать так: ServerSocket(port, 0, InetAddress.getByName(host)) throws IOException Для этого типа сокета порт установки указывается прямо, поэтому, при инициализации, может возникнуть исключение, говорящее о том, что данный порт уже используется либо запрещён к использованию политикой безопасности компьютера.
После установки сокета, вызывается функция
Public Socket accept() throws IOException Эта функция погружает программу в ожидание того момента, когда клиент будет присоединяться к сокету сервера. Как только соединение установлено, функция возвратит объект класса Socket для общения с клиентом.
Клиент-сервер через сокеты. Пример
Как пример - простейшая программа, реализующая работу с сокетами.
Со стороны клиента программа работает следующим образом: клиент подсоединяется к серверу, отправляет данные, после чего получает данные от сервера и выводит их.
Со стороны сервера это выглядит следующим образом: сервер устанавливает сокет сервера на порт 3128, после чего ждёт входящих подключений. Приняв новое подключение, сервер передаёт его в отдельный вычислительный поток. В новом потоке сервер принимает от клиента данные, приписывает к ним порядковый номер подключения и отправляет данные обратно к клиенту.
Логическая структура работы программ-примеров
Программа простого TCP/IP клиента
(SampleClient.java) import java. io.* ; import java. net.* ; class SampleClient extends Thread { public static void main(String args) { try { // открываем сокет и коннектимся к localhost:3128 // получаем сокет сервера Socket s = new Socket("localhost" , 3128 ); // берём поток вывода и выводим туда первый аргумент // заданный при вызове, адрес открытого сокета и его порт args[ 0 ] = args[ 0 ] + "\n" + s. getInetAddress() . getHostAddress() + ":" + s. getLocalPort(); s. getOutputStream() . write(args[ 0 ] . getBytes()); // читаем ответ byte buf = new byte [ 64 * 1024 ]; int r = s. getInputStream() . read(buf); String data = new String(buf, 0 , r); // выводим ответ в консоль System. out. println(data); } catch (Exception e) { System. out. println("init error: " + e);} // вывод исключений } }Программа простого TCP/IP сервера
(SampleServer.java) import java. io.* ; import java. net.* ; class SampleServer extends Thread { Socket s; int num; public static void main(String args) { try { int i = 0 ; // счётчик подключений // привинтить сокет на локалхост, порт 3128 ServerSocket server = new ServerSocket(3128 , 0 , InetAddress. getByName("localhost" )); System. out. println("server is started" ); // слушаем порт while (true) { // ждём нового подключения, после чего запускаем обработку клиента // в новый вычислительный поток и увеличиваем счётчик на единичку new SampleServer(i, server. accept()); i++ ; } } catch (Exception e) { System. out. println("init error: " + e);} // вывод исключений } public SampleServer(int num, Socket s) { // копируем данные this. num = num; this. s = s; // и запускаем новый вычислительный поток (см. ф-ю run()) setDaemon(true); setPriority(NORM_PRIORITY); start(); } public void run() { try { // из сокета клиента берём поток входящих данных InputStream is = s. getInputStream(); // и оттуда же - поток данных от сервера к клиенту OutputStream os = s. getOutputStream(); // буффер данных в 64 килобайта byte buf = new byte [ 64 * 1024 ]; // читаем 64кб от клиента, результат - кол-во реально принятых данных int r = is. read(buf); // создаём строку, содержащую полученную от клиента информацию String data = new String(buf, 0 , r); // добавляем данные об адресе сокета: data = "" + num+ ": " + "\n" + data; // выводим данные: os. write(data. getBytes()); // завершаем соединение s. close(); } catch (Exception e) { System. out. println("init error: " + e);} // вывод исключений } }После компиляции, получаем файлы SampleServer.class и SampleClient.class (все программы здесь и далее откомпилированы с помощью JDK v1.4) и запускаем вначале сервер:
Java SampleServer а потом, дождавшись надписи "server is started", и любое количество клиентов: java SampleClient test1 java SampleClient test2 ... java SampleClient testN
Если во время запуска программы-сервера, вместо строки "server is started" выдало строку типа
Init error: java.net.BindException: Address already in use: JVM_Bind то это будет обозначать, что порт 3128 на вашем компьютере уже занят какой-либо программой или запрещён к применению политикой безопасности.
Заметки
Отметим немаловажную особенность сокета сервера: он может принимать подключения сразу от нескольких клиентов одновременно. Теоретически, количество одновременных подключений неограниченно, но практически всё упирается в мощность компьютеров. Кстати, эта проблема конечной мощности компьютеров используется в DOS атаках на серверы: их просто закидывают таким количеством подключений, что компьютеры не справляются с нагрузкой и "падают".
В данном случае я показываю на примере SimpleServer, как нужно обрабатывать сразу несколько одновременных подключений: сокет каждого нового подключения посылается на обработку отдельному вычислительному потоку.
Стоит упомянуть, что абстракцию Socket - ServerSocket и работу с потоками данных используют C/C++, Perl, Python, многие другие языки программирования и API операционных систем, так что многое из сказанного подходит к применению не только для платформы Java .
Socket vs Socket часть 2, или скажем “нет” протоколу TCP — Архив WASM.RU
В первой части, посвященной основам использованиясокетовMSWindowsв ассемблерных программах, мы говорили о том, что такое сокеты, как они создаются и какие параметры при этом эадаются. Тогда же вскользь было сказано про не ориентированный на соединение протокол UDP, который не гарантирует доставку пакетов, а также очередность их поступления к пункту назначения. В учебном примере тогда использовался наш любимый протокол TCP. И все было у нас хорошо, но в конце остался ряд нерешенных вопросов, в частности, как организовать взаимный обмен между несколькими компьютерами в сети, как передать что-либо сразу многим компьютерам и т.д.
Вообще говоря, прочтение первой части для понимания нынешней совсем не обязательно, хотя по ходу дела я буду постоянно на нее ссылаться. Такие дела. Ха-ха...
Итак, ставим задачу: имеется локальная сеть, скажем, из десятка компьютеров, нужно организовать обмен сообщениями между двумя любыми из них, и (по желанию) между одним и всеми другими.
Слышу, слышу хор подсказок, что мол, используй встроенные возможности Windows, типа:
net send 192.168.0.4 Женя шлет тебе привет!
net send Node4 Жду ответа!
На это есть всего два возражения. Первое, мало ли, что может наша операционная система или другие готовые программы, мы ведь хотим научиться писать свои программы, не так ли? А второе, не факт, что сообщение идет от человека к человеку. В общем случае, оператор может ничего и не знать... А то и не должен ничего знать...
Для меня самым главным в постановке этой задачи было обеспечить возможность передачи чего-либо всем компьютерам сети сразу. Представьте, что мы написали некую программу... Кто сказал - троян? Нет, нет и нет! Никаких троянов. Просто маленькую (очень) бухгалтерскую программу, например. Которая смогла таки через некоторое время поселиться на многих компьютерах нашей локальной сети. И вот приходит назначенное время, пора свести сальдо с бульдо, подвести, так сказать, итог за квартал... Надо сделать все быстро и желательно одновременно. Как это сделать в рамках того материала, что мы изучили в первой части, оставалось неясным.
Ответ, как всегда, дает WindowsAPI. Ищем и находим. Функция sendto () – посылает данные по указанному адресу. А в чем же тогда ее отличие от уже изученной в первой части функции send () ? Оказывается, что sendto () может осуществлять широковещательную передачу по специальному IP – адресу. Но, внимание, это работает только для сокетов типа SOCK_DGRAM! А сокеты, при открытии которых в качестве параметра типа сокета использовалось значение SOCK_DGRAM работают через протокол UDP, а не TCP! Отсюда становится ясно значение подзаголовка этой статьи… Конечно, это всего лишь литературный прием, ни один протокол не лучше и не хуже другого, просто они… разные, вот и все. Хотя оба – это протоколы транспортного уровня, которые “…обеспечивают передачу данных между прикладными процессами”. Оба обращаются к протоколу сетевого уровня, такому, как IP для передачи (приема) данных. Через который далее они (данные) попадают на физический уровень, т.е. в среду передачи… А что там за среда, кто его знает. Может это медный кабель, а может и не среда вовсе, а четверг, и не медный кабель, а эфир…
Схема взаимодействия сетевых протоколов.
UDP – U ser D atagram P rotocol
TCP – T ransmission C ontrol P rotocol
ICMP – I nternet C ontrol M essage P rotocol (протоколобменауправляющимисообщениями)
ARP – A ddress R esolution P rotocol (протокол определения адресов)
В общем, если рисунок ничем Вам не помог, не беда. Важно понять одно, что TCP – протокол транспортного уровня, обеспечивающий надежную транспортировку данных между прикладными процессами, путем установки логического соединения (выделено мной). А UDP – нет. И еще. Где-то там, на прикладном уровне, в одном из пустых прямоугольников и будет находиться наше приложение.
На этом закончим вступительную часть и перейдем к рассмотрению того, как этим пользоваться, с самого начала.
Для демонстрации всего материала, как обычно, используется учебный пример, который можно скачать < >. Пропускаем общую для всех Windows приложений часть и описываем только то, что касается работы сокетов. Сначала необходимо инициализировать Windows Sockets DLL с помощью функции WSAStartup () , которая вернет ноль в случае успешного выполнения, либо, в противном случае, один из кодов ошибки. Затем при инициализации главного окна приложения открываем сокет для приема cообщений:
invoke socket, AF_INET, \
SOCK_DGRAM, \ ; задает тип сокета - протокол UDP!
0 ; тип протокола
If eax != INVALID_SOCKET ; если нет ошибки
mov hSocket, eax ; запомнить дескриптор
После этого, как обычно, надо указать Windows посылать сообщения заданному окну от открытого нами сокета:
invoke WSAAsyncSelect, hSocket, hWnd, WM_SOCKET, FD_READ
где hSocket - дескриптор сокета
hWnd - дескриптор окна, процедуре которого будут посылаться сообщения
WM_SOCKET - сообщение, нами же определенное в секции.const
FD_READ – маска, задающая интересующие нас события, в данном случае это готовность данных от сокета для чтения.Слышу, слышу удивленный хор с отчаянием в голосе: обещали скрытое приложение, а тут главное окно и все такое… Дело в том, что без него не обойтись, т.к. операционная система посылает все сообщения нашему приложению чеpез пpоцедуpу его окна. Выход прост. При необходимости сделайте скрытым это самое главное окно приложения. Как? Например, закомментируйте строку:
invoke ShowWindow, hwnd, SW_SHOWNORMAL
или, что более правильно, используйте:
invoke ShowWindow, hwnd, SW_HIDE
После этого наше приложение также будет запускаться, создаваться главное окно, ему от Windows будет послано сообщение WM_CREATE со всеми вытекающими… Только его окна не будет видно ни на рабочем столе, ни на панели задач. Если это то, чего вы хотели, я рад. В любом случае, продолжаем...
Для этого преобразуем номер порта в сетевой порядок байт с помощью специальной функции АPI:
invoke htons, Port
mov sin.sin_port, ax
mov sin.sin_family, AF_INET
mov sin.sin_addr, INADDR_ANY
Небольшое лирическое отступление, необязательное для понимания смысла этой статьи .
Номера портов для наших сокетов обсуждались в конце первой части. Трудно дать рекомендации по поводу того, какими они должны быть. Единственное, что можно сказать, это то, какими они не могут быть. Неразумно пытаться использовать номера портов, определенные для широко распространенных служб, таких как:
через протоколTCP : 20, 21 – ftp; 23 – telnet; 25 – smtp; 80 – http; 139 - NetBIOS session service;
через протоколUDP : 53 – DNS; 137, 138 – NetBIOS; 161 – SNMP;
Конечно, в составе API есть специальная функция getservbyport () , которая по заданному номеру порта возвращает имя соответствующего ему сервиса. Вернее, сама функция возвращает указатель на структуру, внутри которой есть указатель на это имя...
Вызвать ее можно так:
invoke htons, Port; преобразуем номер порта в сетевой порядок байт
invoke getservbyport, ax, 0;
Обратите внимание на то, что сообщает Win32 Programmer’sReference по поводу getservbyport :
“...возвращает указатель на структуру, которая распределена Windows Sockets. Приложение никогда не должно пытаться изменять эту структуру или любой из ее компонентов. Кроме того, только одна копия этой структуры распределена для потока , так что приложение должно скопировать любую информацию, которая ему требуется, перед любым другим вызовом функции Windows Sockets”.
А вот и сама структура:
s_name DWORD ?; указатель на строку с именем сервиса
s_aliases DWORD ?;
s_port WORD ?; номер порта
s_proto DWORD ?;
Есть в API, так сказать, и “парная” функция: getservbyname() , которая по имени сервиса возвращает информацию о номере используемого порта.
К сожалению, практической пользы из этих функций для нас извлечь не удастся. Так что, знайте, что они есть и забудьте о них...
invoke bind, hSocket, addr sin, sizeof sin
If eax == SOCKET_ERROR; если ошибка
invoke MessageBox, NULL, addr …
На этом подготовительную работу по созданию и настройке принимающего сокета с использованием датаграмм можно считать законченной. Нет необходимости устанавливать сокет в состояние cлушания порта функцией invoke listen , как мы это делали для сокета типа SOCK_STREAM в первой части. Теперь в процедуре главного окна нашего приложения мы можем добавить код, который будет выполняться при поступлении сообщения WM_SOCKET от сокета:
; если получено сообщение от сокета (hSocket)
Elseif uMsg == WM_SOCKET
If ax == FD_READ;
If ax == NULL ; отсутствует ошибка
; принять данные (64 байта) от сокета в буфер BytRecu
invoke recv, hSocket, addr BytRecu, 64, 0;
Теперь о том, как открыть сокет для передачи сообщений. Вот все необходимые действия программы:
invoke socket, AF_INET, SOCK_DGRAM, 0
invoke htons, Port
mov sin_to.sin_port, ax
mov sin_to.sin_family, AF_INET
invoke inet_addr, addr AdresIP
mov sin_to.sin_addr, eax
Когда дело доходит до передачи данных, достаточно сделать cледующее:
invoke sendto, hSocket1, addr BytSend1, 64, 0, \
addr sin_to, sizeof sin_to
Значения параметров при вызове этой функции APIследующие:
hSocket1 - дескриптор ранее открытого сокета
addrBytSend1 - адрес буфера, содержащего данные на передачу
64 - размер данных вбуфере, в байтах
0 - индикатор…, в примере MSDNэто просто 0
addrsin_to - указатель наструктуру, которая содержит адрес назначения
sizeofsin_to – размер этой структуры в байтах.Если при выполнении функции sendto () не возникло ошибок, то она возвращает число переданных байт, иначе на выходе имеем в eaxзначение SOCKET_ERROR.
Теперь самое время поговорить о том самом широковещательном адресе, о котором упоминалось вначале. В структуре
мы предварительно заполнили поле с IP - адресом назначения, указывая, куда, собственно, отправлять данные. Если это адрес 127.0.0.1 – естественно, никуда дальше собственного компьютера наши данные не уйдут. В литературе четко сказано, что пакет, посланный в сеть с адресом 127.x.x.x, не будет передаваться ни по какой сети. Более того, маршрутизатор или шлюз никогда не должен распространять информацию о маршрутах для сети с номером 127 - этот адрес не является адресом сети. Чтобы отправить “передачку” сразу всем компьютерам локальной сети нужно использовать адрес, сформированный из нашего собственного IP – адреса, но имеющий все единицы в младшем октете, что-нибудь типа 192.168.0.255. Вот, собственно, и все. В момент закрытия программы необходимо закрыть сокеты и освободить ресурсы Sockets DLL, делается это просто:
invoke closesocket, hSocket
invoke closesocket, hSocket1
invoke WSACleanup
Для мультипотоковых приложений после WSACleanup завершаются операции с сокетами для всех потоков.
Самым трудным в этой статье было для меня решить, как лучше всего проиллюстрировать использование Windows Sockets API. Один подход вы, наверное, уже увидели, когда в едином приложении одновременно использовался и сокет на прием, и сокет на передачу сообщений. Не менее привлекательным кажется и другой способ, когда код для одного и другого четко разделен, вплоть то того, что существует в разных приложениях. В конце концов, я реализовал еще и этот способ, который может оказаться для понимания начинающими несколько проще. Во втором <архиве
Безэтогофункцияsend() выдаст SOCKET_ERROR!
Напоследок можно отметить некоторые общие проблемы, возникающие при работе с сокетами. Чтобы обработать оконное сообщение, информирующее о том, что изменилось состояние сокета, мы, как обычно, использовали прямые сообщения от Windows главному окну приложения. Есть и другой подход, когда создают отдельные окна для каждого сокета.
Вообще говоря, централизованная обработка сообщений главным окном – это, как кажется, более простой для понимания метод, который, тем не менее, на практике может добавить хлопот. Если программой используется больше чем один сокет в одно и то же время, нужно хранить список дескрипторов сокетов. При появлении сообщения от сокетов, главная оконная процедура в списке ищет информацию, связанную с этим дескриптором сокета и отправляет сообщение об изменении состояния далее в предназначенную для этого процедуру. Которая уже тем или иным способом реагирует, что-то там делает... Этот подход вынуждает обработку сетевых задач интегрировать в ядро программы, что затрудняет создание библиотек сетевых функций. Каждый раз, когда используются эти сетевые функции, в главный оконный обработчик приложения нужно добавлять дополнительный код.
Во втором методе обработки сообщений для их получения приложение создает скрытое окно. Оно служит для отделения главной оконной процедуры приложения от обработки сетевых сообщений. Этот подход может упростить главное приложение и облегчить использование имеющегося сетевого кода в других программах. Отрицательной стороной такого подхода является чрезмерное использование Windows - user памяти, т.к. для каждого созданного окна резервируется довольно большой его объем.
Какой способ выбрать - решайте сами. И еще одно. На время экспериментов, возможно, придется отключить ваш персональный firewall. Так, например, Outpost Pro 2.1.275 в режиме обучения реагировал на попытку передачи в сокет, но, когда передача вручную разрешалась, данные все равно не доходили. Вот вам и UDP. Хотя дело может быть и не в этом. Проблем с моим ZoneAlarmPro 5.0.590 в такой же ситуации не было.
P. S. Заканчивая вторую часть статьи случайно наткнулся в сети на исходники трояна на нашем любимом языке MASM. Все компилируется и запускается, одно но, клиент не хочет коннектиться с сервером, да еще под Windows 2000 sp4 иногда вылетает с ошибкой, мол, приложение будет закрыто и все такое… Лично мне в этом трояне нравится, что программа не просто там ведет лог нажатий, или “выдирает” файл с паролями и отсылает его по электронке, а имеет широкий набор управляемых дистанционно функций, дольно оригинально реализованных. Если получится привести все это хозяйство в чувство, то, возможно, скоро появится и третья часть, посвященная описанию конкретной реализации… Для тех, кто внимательно прочитал обе статьи и разобрался с работой функций сокет API, там нет ничего сложного. Вроде бы… Кстати, сам автор пишет в readme, что написал его (троян) в образовательных целях. Ну-ну. Этим и воспользуемся.
DirectOr
Сокеты
Сокет - это один конец двустороннего канала связи между двумя программами, работающими в сети. Соединяя вместе два сокета, можно передавать данные между разными процессами (локальными или удаленными). Реализация сокетов обеспечивает инкапсуляцию протоколов сетевого и транспортного уровней.
Первоначально сокеты были разработаны для UNIX в Калифорнийском университете в Беркли. В UNIX обеспечивающий связь метод ввода-вывода следует алгоритму open/read/write/close. Прежде чем ресурс использовать, его нужно открыть, задав соответствующие разрешения и другие параметры. Как только ресурс открыт, из него можно считывать или в него записывать данные. После использования ресурса пользователь должен вызывать метод Close(), чтобы подать сигнал операционной системе о завершении его работы с этим ресурсом.
Когда в операционную систему UNIX были добавлены средства межпроцессного взаимодействия (Inter-Process Communication, IPC) и сетевого обмена, был заимствован привычный шаблон ввода-вывода. Все ресурсы, открытые для связи, в UNIX и Windows идентифицируются дескрипторами. Эти дескрипторы, или описатели (handles) , могут указывать на файл, память или какой-либо другой канал связи, а фактически указывают на внутреннюю структуру данных, используемую операционной системой. Сокет, будучи таким же ресурсом, тоже представляется дескриптором. Следовательно, для сокетов жизнь дескриптора можно разделить на три фазы: открыть (создать) сокет, получить из сокета или отправить сокету и в конце концов закрыть сокет.
Интерфейс IPC для взаимодействия между разными процессами построен поверх методов ввода-вывода. Они облегчают для сокетов отправку и получение данных. Каждый целевой объект задается адресом сокета, следовательно, этот адрес можно указать в клиенте, чтобы установить соединение с целью.
Типы сокетов
Существуют два основных типа сокетов - потоковые сокеты и дейтаграммные.
Потоковые сокеты (stream socket)
Потоковый сокет - это сокет с установленным соединением, состоящий из потока байтов, который может быть двунаправленным, т, е. через эту конечную точку приложение может и передавать, и получать данные.
Потоковый сокет гарантирует исправление ошибок, обрабатывает доставку и сохраняет последовательность данных. На него можно положиться в доставке упорядоченных, сдублированных данных. Потоковый сокет также подходит для передачи больших объемов данных, поскольку накладные расходы, связанные с установлением отдельного соединения для каждого отправляемого сообщения, может оказаться неприемлемым для небольших объемов данных. Потоковые сокеты достигают этого уровня качества за счет использования протокола Transmission Control Protocol (TCP) . TCP обеспечивает поступление данных на другую сторону в нужной последовательности и без ошибок.
Для этого типа сокетов путь формируется до начала передачи сообщений. Тем самым гарантируется, что обе участвующие во взаимодействии стороны принимают и отвечают. Если приложение отправляет получателю два сообщения, то гарантируется, что эти сообщения будут получены в той же последовательности.
Однако, отдельные сообщения могут дробиться на пакеты, и способа определить границы записей не существует. При использовании TCP этот протокол берет на себя разбиение передаваемых данных на пакеты соответствующего размера, отправку их в сеть и сборку их на другой стороне. Приложение знает только, что оно отправляет на уровень TCP определенное число байтов и другая сторона получает эти байты. В свою очередь TCP эффективно разбивает эти данные на пакеты подходящего размера, получает эти пакеты на другой стороне, выделяет из них данные и объединяет их вместе.
Потоки базируются на явных соединениях: сокет А запрашивает соединение с сокетом В, а сокет В либо соглашается с запросом на установление соединения, либо отвергает его.
Если данные должны гарантированно доставляться другой стороне или размер их велик, потоковые сокеты предпочтительнее дейтаграммных. Следовательно, если надежность связи между двумя приложениями имеет первостепенное значение, выбирайте потоковые сокеты.
Сервер электронной почты представляет пример приложения, которое должно доставлять содержание в правильном порядке, без дублирования и пропусков. Потоковый сокет рассчитывает, что TCP обеспечит доставку сообщений по их назначениям.
Дейтаграммные сокеты (datagram socket)
Дейтаграммные сокеты иногда называют сокетами без организации соединений, т. е. никакого явного соединения между ними не устанавливается - сообщение отправляется указанному сокету и, соответственно, может получаться от указанного сокета.
Потоковые сокеты по сравнению с дейтаграммными действительно дают более надежный метод, но для некоторых приложений накладные расходы, связанные с установкой явного соединения, неприемлемы (например, сервер времени суток, обеспечивающий синхронизацию времени для своих клиентов). В конце концов на установление надежного соединения с сервером требуется время, которое просто вносит задержки в обслуживание, и задача серверного приложения не выполняется. Для сокращения накладных расходов нужно использовать дейтаграммные сокеты.
Использование дейтаграммных сокетов требует, чтобы передачей данных от клиента к серверу занимался User Datagram Protocol (UDP) . В этом протоколе на размер сообщений налагаются некоторые ограничения, и в отличие от потоковых сокетов, умеющих надежно отправлять сообщения серверу-адресату, дейтаграммные сокеты надежность не обеспечивают. Если данные затерялись где-то в сети, сервер не сообщит об ошибках.
Кроме двух рассмотренных типов существует также обобщенная форма сокетов, которую называют необрабатываемыми или сырыми.
Сырые сокеты (raw socket)
Главная цель использования сырых сокетов состоит в обходе механизма, с помощью которого компьютер обрабатывает TCP/IP. Это достигается обеспечением специальной реализации стека TCP/IP, замещающей механизм, предоставленный стеком TCP/IP в ядре - пакет непосредственно передается приложению и, следовательно, обрабатывается гораздо эффективнее, чем при проходе через главный стек протоколов клиента.
По определению, сырой сокет - это сокет, который принимает пакеты, обходит уровни TCP и UDP в стеке TCP/IP и отправляет их непосредственно приложению.
При использовании таких сокетов пакет не проходит через фильтр TCP/IP, т.е. никак не обрабатывается, и предстает в своей сырой форме. В таком случае обязанность правильно обработать все данные и выполнить такие действия, как удаление заголовков и разбор полей, ложится на получающее приложение - все равно, что включить в приложение небольшой стек TCP/IP.
Однако нечасто может потребоваться программа, работающая с сырыми сокетами. Если вы не пишете системное программное обеспечение или программу, аналогичную анализатору пакетов, вникать в такие детали не придется. Сырые сокеты главным образом используются при разработке специализированных низкоуровневых протокольных приложений. Например, такие разнообразные утилиты TCP/IP, как trace route, ping или arp, используют сырые сокеты.
Работа с сырыми сокетами требует солидного знания базовых протоколов TCP/UDP/IP.
Порты
Порт определен, чтобы разрешить задачу одновременного взаимодействия с несколькими приложениями. По существу с его помощью расширяется понятие IP-адреса. Компьютер, на котором в одно время выполняется несколько приложений, получая пакет из сети, может идентифицировать целевой процесс, пользуясь уникальным номером порта, определенным при установлении соединения.
Сокет состоит из IP-адреса машины и номера порта, используемого приложением TCP. Поскольку IP-адрес уникален в Интернете, а номера портов уникальны на отдельной машине, номера сокетов также уникальны во всем Интернете. Эта характеристика позволяет процессу общаться через сеть с другим процессом исключительно на основании номера сокета.
За определенными службами номера портов зарезервированы - это широко известные номера портов, например порт 21, использующийся в FTP. Ваше приложение может пользоваться любым номером порта, который не был зарезервирован и пока не занят. Агентство Internet Assigned Numbers Authority (IANA) ведет перечень широко известных номеров портов.
Обычно приложение клиент-сервер, использующее сокеты, состоит из двух разных приложений - клиента, инициирующего соединение с целью (сервером), и сервера, ожидающего соединения от клиента.
Например, на стороне клиента, приложение должно знать адрес цели и номер порта. Отправляя запрос на соединение, клиент пытается установить соединение с сервером:
Если события развиваются удачно, при условии что сервер запущен прежде, чем клиент попытался с ним соединиться, сервер соглашается на соединение. Дав согласие, серверное приложение создает новый сокет для взаимодействия именно с установившим соединение клиентом:
Теперь клиент и сервер могут взаимодействовать между собой, считывая сообщения каждый из своего сокета и, соответственно, записывая сообщения.
Работа с сокетами в.NET
Поддержку сокетов в.NET обеспечивают классы в пространстве имен System.Net.Sockets - начнем с их краткого описания.
| Класс | Описание |
|---|---|
| MulticastOption | Класс MulticastOption устанавливает значение IP-адреса для присоединения к IP-группе или для выхода из нее. |
| NetworkStream | Класс NetworkStream реализует базовый класс потока, из которого данные отправляются и в котором они получаются. Это абстракция высокого уровня, представляющая соединение с каналом связи TCP/IP. |
| TcpClient | Класс TcpClient строится на классе Socket, чтобы обеспечить TCP-обслуживание на более высоком уровне. TcpClient предоставляет несколько методов для отправки и получения данных через сеть. |
| TcpListener | Этот класс также построен на низкоуровневом классе Socket. Его основное назначение - серверные приложения. Он ожидает входящие запросы на соединения от клиентов и уведомляет приложение о любых соединениях. |
| UdpClient | UDP - это протокол, не организующий соединение, следовательно, для реализации UDP-обслуживания в.NET требуется другая функциональность. |
| SocketException | Это исключение порождается, когда в сокете возникает ошибка. |
| Socket | Последний класс в пространстве имен System.Net.Sockets - это сам класс Socket. Он обеспечивает базовую функциональность приложения сокета. |
Класс Socket
Класс Socket играет важную роль в сетевом программировании, обеспечивая функционирование как клиента, так и сервера. Главным образом, вызовы методов этого класса выполняют необходимые проверки, связанные с безопасностью, в том числе проверяют разрешения системы безопасности, после чего они переправляются к аналогам этих методов в Windows Sockets API.
Прежде чем обращаться к примеру использования класса Socket, рассмотрим некоторые важные свойства и методы этого класса:
| Свойство или метод | Описание |
|---|---|
| AddressFamily | Дает семейство адресов сокета - значение из перечисления Socket.AddressFamily. |
| Available | Возвращает объем доступных для чтения данных. |
| Blocking | Дает или устанавливает значение, показывающее, находится ли сокет в блокирующем режиме. |
| Connected | Возвращает значение, информирующее, соединен ли сокет с удаленным хостом. |
| LocalEndPoint | Дает локальную конечную точку. |
| ProtocolType | Дает тип протокола сокета. |
| RemoteEndPoint | Дает удаленную конечную точку сокета. |
| SocketType | Дает тип сокета. |
| Accept() | Создает новый сокет для обработки входящего запроса на соединение. |
| Bind() | Связывает сокет с локальной конечной точкой для ожидания входящих запросов на соединение. |
| Close() | Заставляет сокет закрыться. |
| Connect() | Устанавливает соединение с удаленным хостом. |
| GetSocketOption() | Возвращает значение SocketOption. |
| IOControl() | Устанавливает для сокета низкоуровневые режимы работы. Этот метод обеспечивает низкоуровневый доступ к лежащему в основе классу Socket. |
| Listen() | Помещает сокет в режим прослушивания (ожидания). Этот метод предназначен только для серверных приложений. |
| Receive() | Получает данные от соединенного сокета. |
| Poll() | Определяет статус сокета. |
| Select() | Проверяет статус одного или нескольких сокетов. |
| Send() | Отправляет данные соединенному сокету. |
| SetSocketOption() | Устанавливает опцию сокета. |
| Shutdown() | Запрещает операции отправки и получения данных на сокете. |