Сервер по сравнению с Клиентским Сокетом (Низкоуровневые детали)?

Код var t = 1 / steps; делает целочисленное деление, , поэтому результат t равен нулю

Также обратите внимание, что j = j + t выполняется после каждого цикла, поэтому при первая итерация j==0

Этот недостаток вызывает такую ​​проблему: и b, и a равны на первой итерации, потому что j все еще остается = 0. Таким образом, вы рассчитываете длину сегмента на интервалах: 0-0, 0-0.1, 0.1-0.2...0.7-0.8,0.8-0.9 - игнорирование 0.9-1.0 интервала

15
задан S M Kamran 21 April 2009 в 20:57
поделиться

4 ответа

Во-первых, серверные сокеты обычно связаны с хорошо известными именами (в данном случае с портами), и они устанавливаются с помощью listen () . В этом и заключается реальная разница, поскольку клиентские сокеты устанавливаются с помощью connect () . Вызов listen () для сокета приводит к тому, что реализация ядра tcp / ip начинает принимать соединения, отправленные на связанное имя сокета (порт). Это произойдет независимо от того, вызываете ли вы когда-либо accept () .

accept () просто дает вашему серверу возможность доступа и взаимодействия с клиентскими сокетами, которые подключены к вашему прослушивающему сокету.

16
ответ дан 1 December 2019 в 00:01
поделиться

At a low level sockets are just sockets regardless of whether they are being used in a server or client application. The difference between the two lies in the system calls each kind of application makes.

Server sockets will call bind() to be associated with a port. They want to be associated with a port so that other programs know where to reach them. Client sockets can call bind() but almost never do because there is not much point. If a socket doesn't call bind() the OS will just choose an ephemeral port for it, which is fine for clients because they are doing the calling; no one needs to call them.

Server sockets call listen(). This was explained pretty well in the other answers.

Server sockets call accept() and I think this is the crux of your question because it is a bit mysterious at first. The important thing to grasp is that in calling accept() the kernel will pass back a new socket. It is now separate from the original listening socket and is what your server will use to communicate with its peer(s).

The key in understanding how the listening socket continues to listen while the accepted connection is doing its thing is in understanding that tcp connections depend on a 4-tuple of (1) local address (2) local port (3) foreign address (4) foreign port. These define a unique connection. Before accept() passed back the new socket the kernel used these values to create various structures so that in collaboration with the tcp/ip stack all traffic with this tuple will go to the connected socket. Even though your server may have a thousand connections with local address 192.168.1.100 port 80, the client combination of address and port will always be different and thus the tuple is always unique.

32
ответ дан 1 December 2019 в 00:01
поделиться

Если вы действительно заинтересованы, то я бы посоветовал вам прочитать Иллюстрированный TCP / IP, том 2 . Если вы хотите получить ответ «меньше в духе», то:

  • Серверные сокеты связаны с известными конечными точками, где конечной точкой является кортеж (протокол, адрес, порт). Конечная точка формируется протоколом, указанным в системном вызове socket () , и адресной информацией, указанной в системном вызове bind () .
  • Когда сервер вызывает ] listen () системный вызов, сетевой стек создает очередь, в которую помещаются ожидающие соединения. Подсказка к размеру очереди задается в качестве параметра backlog для listen () .
  • Затем сервер вызывает accept () , чтобы получить новое соединение из очереди.
  • Клиентские сокеты отправляют сообщения на серверные сокеты, указывая конечную точку сервера при вызове connect () и затем отправляя данные с помощью send () или write () .
  • Когда клиент вызывает connect () , соединение помещается в очередь на стороне сервера, где оно находится, пока сервер не примет соединение .

This Однако описание действительно только для сокетов TCP / IP. Случай UDP проще и совершенно другой, так как сокеты UDP не обязательно подключены.

соединение помещается в очередь на стороне сервера, где оно находится, пока сервер не примет соединение .

Однако это описание действительно действительно только для сокетов TCP / IP. Случай UDP проще и совершенно другой, так как сокеты UDP не обязательно подключены.

соединение помещается в очередь на стороне сервера, где оно находится, пока сервер не примет соединение .

Однако это описание действительно действительно только для сокетов TCP / IP. Случай UDP проще и совершенно другой, так как сокеты UDP не обязательно подключены.

10
ответ дан 1 December 2019 в 00:01
поделиться

Трудно полностью ответить на ваш вопрос без указания языка программирования. Я отвечу относительно python, потому что, насколько я знаю, ответ может быть репрезентативным.

Если s является объектом socket , то сервер сначала связывается с портом позвонив по телефону s.bind (('', 12345)) . Это создает сокет в режиме сервера. Он готов перехватить данные через порт 12345.

Затем вызывается s.listen (10) . Это переводит сокет в режим сервера. Это означает, что запрос на соединение будет получен этим сокетом (до 10 ожидающих запросов одновременно).

К тому времени, как мы получим s.accept () , операционная система уже знает, что мы слушаем порт 12345. s.accept () просто говорит, что мы собираемся делать с полученными нами запросами. В python s.accept () вернет (соединение, адрес) , где соединение - это соединение через другой порт. В этом случае соединение не очень отличается от объекта сокета, который открыл клиент. Это достаточно симметрично с этого момента.

3
ответ дан 1 December 2019 в 00:01
поделиться
Другие вопросы по тегам:

Похожие вопросы: