Создание протокола прикладного уровня

@fklm1994 · Регистрация: 15.06.2013

Студворк — интернет-сервис помощи студентам

Доброго времени суток, форумчане!

Недавно решил поставить себе цель написать собственный протокол прикладного уровня. Протокол хочу использовать для передачи данных через сеть(как медиафайлы, так и какие либо команды). Имею примерное представление того, как будет выглядеть отсылаемый пакет данных, но, к сожалению, не знаю какой язык использовать и как, примерно, это всё реализуется. Буду при знателен, если вы меня подталкнёте в правильное русло.

raxper · 08.09.2013, 13:55

...язык по сути не важен. Начните с изучения простых и известных протоколов поверх TCP/IP. Рекомендую почитать http://cnp3book.info.ucl.ac.be/

@locm · 11.09.2013, 11:58

Язык по сути не важен. Главное чтобы в нем была возможность работы с сетью (или хотя бы доступ к API OS).

Думаю что стоит начать с изучения уже имеющихся, например, протокола передачи данных в торрент-сети. Он не сложный (меньше 10 команд) и позволяет передавать как данные (файлы), так и служебные сообщения.

Описание протокола

Сообщения

Все остальные сообщения в протоколе принимают форму <length prefix><message ID><payload>. Длина префикса состоит из четырех байт big-endian значения. Идентификатор сообщения - это один десятичный символ. Полезная нагрузка (payload) непосредственно зависит от сообщения.

keep-alive: <len=0000>

keep-alive сообщения - это сообщения с нулевыми байтами, length prefix установлен в ноль. Не существует идентификатора сообщения и никакой полезной нагрузки сообщение не несёт. Пир может закрыть соединение, если он не получают никаких сообщений (keep-alive или любого другого сообщения) в течение определенного периода времени, поэтому keep-alive сообщение нацелено на поддержание связи. Это время, обычно равно двум минутам.

choke: <len=0001><id=0>

Choke-сообщение - это сообщение фиксированной длины без полезной нагрузки.

unchoke: <len=0001><id=1>

Unchoke-сообщение - это сообщение фиксированной длины без полезной нагрузки.

interested: <len=0001><id=2>

Interested-сообщение - это сообщение фиксированной длины без полезной нагрузки.

not interested: <len=0001><id=3>

Non interested-сообщение - это сообщение фиксированной длины без полезной нагрузки.

have: <len=0005><id=4><piece index>

Have-сообщение фиксированной длины. Полезная нагрузка - это с указвнием нулей (zero-based) индекс куска, который только что был успешно скачан и проверен с помощью хэша.

Конструкторское замечание: Это строгое определение, в реальности some games may be played. В частности, поскольку крайне маловероятно, чтобы пиры загружали куски, которые они уже имеют, пир может не рекламировать (advertise) наличие кусков пирам, которые эти куски имеют. Подавление HAVE-сообщений ("HAVE supression") как минимум приведет к 50% сокращению числа сообщений, а это сокращение примерно на 25-35% накладных расходов протокола (protocol overhead). В то же время, возможно целесообразно отправить HAVE-сообщение пирам, которые уже имеют этот кусок, поскольку он будет полезен в определении его редкости.

Вредоносные пиры также могут выбирать оглашение (advertise) имеющихся кусков, которые пир точно никогда не загрузит. Due to this attempting to model peers using this information is a bad idea

bitfield: <len=0001+X><id=5><bitfield>

Bitfield сообщение может быть направлено сразу же после того, последовательность "рукопожатий" будет завершена, и до любых других сообщений. Оно является необязательным, и клиентам, не имеющих куски, нет нужды отсылать его.

Bitfield сообщение переменной длины, где X - это длина bitfield'a. Полезная нагрузка сообщения - bitfield представление кусков, которые были успешно загружены. Старший разряд в первом байте соответствует куску с индексом 0. Биты, которые пустые указывают пропавший кусок, а установленные биты обозначают валидные и доступные куски. Запасные биты в конце устанавливаются в ноль.

Bitfield неверной длины считается ошибочным. Клиенты должны разорвать соединение, если они получают bitfields неверного размера, или если bitfield имеет произвольный набор запасных битов.

request: <len=0013><id=6><index><begin><length>

Сообщение-запрос фиксированной длины, используется для запросы блока. Полезная нагрузка сообщения содержит следующую информацию:

index: целое число, определяющее с указанием нулей (zero-based) индекс куска

begin: целое с указанием нулей смещение байтов внутри куска

length: целое число, определяющее запрашиваемую длину.

This section is under dispute! Please use the discussion page to resolve this!

View 1. Согласно официальной спецификациям, "Все текущие реализаций используют 2^15 (32KB) куски, и закрывают соединения, которые запрашивают количество данных более 2^17 (128Kb)." Уже в версии 3 или 2004, это поведение было изменено на использование 2^14 (16Кб) блоков. Начиная с версии 4.0 или mid-2005, соединение в Mainline при запросах больше, чем 2^14 (16Кб), и некоторые клиенты последовали этому примеру. Помните, что block-запросы меньше, чем куски (>= 2^18 байт), поэтому будут необходимы многочисленные запросы, чтобы скачать весь кусок.

Собственно, спецификация позволяет 2^15 (32Кб) запросы. Реальность такова, что все клиенты начиная с сегодняшнего момента будут использовать 2 ^ 14 (16Кб) запросы. Из-за клиентов, которые привязаны к такому размеру запросов, рекомендуется реализовывать программы, делающие запросы именно такого размера. Меньшие размеры запросов приводят к повышению накладных расходов в связи с увеличением количества требуемых запросов, проектировщики советуют не делать размер запросов меньше, чем 2 ^ 14 (16Кб).

Выбор предельного размера запрашиваемого блока не очень ясен. Mainline версии 4 осуществляет 16Кб-ые запросы, большинство клиентов будут использовать этот размер. В то же время размер 2^14 (16Кб) представляется полу-официальным (наполовину официальным, потому что официальная документация протокола не обновлялась) , поэтому, по сути, неправильным (не соответствующим спецификации). В то же время, разрешение бо'льших запросов расширяет набор возможных пиров, и при исключении очень низкой пропускной способности соединения (<256кб/сек), несколько блоков будет загружено в один choke-timeperiod, таким образом простое предписание старого предела размера блока вызывает минимальное ухудшение работы. Из-за этого фактора, рекомендуется только старое 2^17 (128 КБ) максимальное ограничение размера.

View 2. Текущая версия имеет по крайней мере следующие ошибки: Mainline начали использовать 2^14 (16384) байт запросы, когда он был единственным из существующих клиентов, только "официальная спецификация" все ещё говорила об устаревшем 32768-байтовом значении, которое не было в действительности ни размером значения по умолчанию, ни позволенным максимумом. В версии 4 поведение запросов не изменилось, но максимально допустимый размер запроса стал равным значению размера по умолчанию. В последней версии Mainline максимум изменился до 32768 (заметьте, что это первое появление 32768 либо для значения по умолчанию, либо для максимального размера запроса с момента появления первой версии). Утверждение: "большинство старых клиентов используют 32KB запросы" - является ложным. Обсуждение запросов не принимает последствия латентности во внимание.

piece: <len=0009+X><id=7><index><begin><block >

Piece-сообщение переменной длины, где X - длина блока. Полезная нагрузка сообщения содержит следующую информацию:

index: целое определяющее с указанием нулей индекс куска

begin: целое, определяющее с указанием нулей байтовое смещение внутри куска

block: блок данных, который есть подмножество куска с определённым индексом

cancel: <len=0013><id <= 8><index><begin><length>

Cancel-сообщение фиксированной длины, используется для отмены блокировки запросов. Полезная нагрузка сообщения идентична той, которая была в "сообщении-запросе" ("request" message). Сообщение обычно используется во время стратегии "Конца игры" (End game, см. ниже раздел Алгоритмы).

port: <len=0003><id=9><listen-port>

Port-сообщение отсылается посредством новых версий Mainline, которая реализует DHT Tracker. Порт для прослушивания является портом который DHT узел прослушивает. Этот пир должен быть вставлен в локальную таблицу маршрутизации (если DHT Tracker поддерживается).

Главное понять саму суть устройства подобных протоколов. Через сеть вы передаете и принимаете массив (поток) данных и в них должны быть специальные метки чтобы можно было этот массив разобрать на приемной стороне. Среди таких моток должны быть как минимум, команда (тип данных) и длина пакета с данными. Таким образом, при приеме массива данных из сети, будет информация, во первых о типе пакета, необходимая для его правильной обработки, а во вторых, длина пакета, необходимая чтобы точно знать каков его размер. Это можно описать примерно такой структурой (ЯП в данном случае не имеет значения).

PureBasic
1
2
3
4
Structure NetPacket_Header 
  Size.u  ; 2 байта.
  Type.u  ; 2 байта.
EndStructure

Эта структура является заголовком пакета и должна быть в его начале, и за ней следуют данные. Поле Size определяет размер пакета. В данном случае, его размер не может превышать 64 КБ, но если увеличить размер поля до 4-ёх байт, то появится возможность передавать пакеты имеющие размер до 4 ГБ. Но это нежелательно, поскольку если потеряется пакет не большого размера, то его быстрее можно будет повторно отправить. Поле Type определяет тип пакета (команду), необходимую для правильной обработки пакета на приемной стороне.
Если протокол реализован поверх UDP, или другого низкоуровневого протокола, то не помешает добавить так же поле с контрольной суммой пакета, чтобы удостоверится в целостности данных.

Есть еще один момент, на который необходимо обратить внимание. Пакет может быть принят не за один раз (вызов принимающей функции из сети) или наоборот, за раз может быть принято несколько пакетов, причем последний из них может быть принят не полностью. Поэтому так же необходим промежуточный буфер, в который будут записываться все данные, принимаемые из сети, а затем, по мере получения целых пакетов, уже обрабатываться.

Реализация в коде (сервер и клиент) всего вышенаписанного. Для примера, реализованы две команды:

PureBasic
1
2
#NetPacketType_EndProg ; Завершить работу клиента.
#NetPacketType_Data    ; Данные.

Код сервера и клиента

Сервер.

PureBasic
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
Enumeration 
  #NetPacketType_EndProg 
  #NetPacketType_Data 
EndEnumeration 
 
Structure NetPacket_Header 
  Size.u 
  Type.u 
EndStructure 
 
Structure NetPacket_EndData 
  Header.NetPacket_Header 
EndStructure 
 
Structure NetPacket_Data 
  Header.NetPacket_Header 
  Buff.a[0] 
EndStructure 
 
EndData.NetPacket_EndData 
 
 
Procedure Send(Connect, String.s) 
  NetPacket_Data.NetPacket_Data 
  
  NetPacket_Data\Header\Size = SizeOf(NetPacket_Header)+StringByteLength(String) 
  NetPacket_Data\Header\Type = #NetPacketType_Data 
  
  SendNetworkData(Connect, @NetPacket_Data\Header, SizeOf(NetPacket_Header)) 
  SendNetworkData(Connect, @String, StringByteLength(String)) 
  
EndProcedure 
 
If InitNetwork() = 0 
  MessageRequester("Error", "Can't initialize the network !", 0) 
  End 
EndIf 
 
Port = 2222 
*Buffer = AllocateMemory(1000) 
 
If CreateNetworkServer(0, Port) 
  
  Repeat 
    
    SEvent = NetworkServerEvent() 
    
    If SEvent 
      
      ClientID = EventClient() 
      
      Select SEvent 
          
        Case #PB_NetworkEvent_Connect 
          
          Send(ClientID, "Первая строка") 
          Send(ClientID, "Еще строка") 
          Send(ClientID, "Строка № 3") 
          Send(ClientID, "Больше нет строк") 
          
          EndData\Header\Size = SizeOf(NetPacket_Header) 
          EndData\Header\Type = #NetPacketType_EndProg 
          SendNetworkData(ClientID, @EndData, SizeOf(NetPacket_Header)) 
          
        Case #PB_NetworkEvent_Disconnect 
          MessageRequester("PureBasic - Server", "Client "+Str(ClientID)+" has closed the connection...", 0) 
          Quit = 1 
          
      EndSelect 
    EndIf 
    
  Until Quit = 1 
  
  MessageRequester("PureBasic - Server", "Click to quit the server.", 0) 
  
  CloseNetworkServer(0) 
Else 
  MessageRequester("Error", "Can't create the server (port in use ?).", 0) 
EndIf 
 
 
End

Клиент.

PureBasic
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
Structure NetBuff_Param 
  *Buff 
  Len.l 
  Pos.l 
EndStructure 
 
EnableExplicit 
 
Procedure NetBuff_ReallocateMemory(*Buff.NetBuff_Param, AddBytes) ; Нужно ли увеличить память под данные? 
  Protected Len, Pos, NewLen, *Point 
  Protected *NewPoint, i 
  
  Len = *Buff\Len 
  Pos = *Buff\Pos 
  *Point = *Buff\Buff 
  
  If AddBytes>0 
    NewLen = 0 
    If Pos>Len Or Len-Pos < AddBytes Or *Point=0; Нужно изменить (увеличить) размер памяти. 
      NewLen = Len+AddBytes+100 
    ElseIf Len-Pos > AddBytes+400 ; Памяти выделено слишком много и надо уменьшить. 
      NewLen = AddBytes+Pos+80 
    EndIf 
    
    If NewLen > 0 
      For i=1 To 4 
        *NewPoint = ReAllocateMemory(*Point, NewLen) 
        If *NewPoint 
          *Buff\Buff = *NewPoint 
          *Buff\Len = NewLen 
          If *Buff\Len>NewLen 
            *Buff\Len=NewLen 
          EndIf 
          Len = NewLen 
          Break 
        Else 
          Delay(4) 
        EndIf 
      Next i 
    EndIf 
    
  EndIf 
  
  ProcedureReturn Len 
EndProcedure 
 
 
Procedure NetBuff_AddMem(*Buff.NetBuff_Param, *Mem, AddBytes) ; Добавление принятых данных, в память еще необработанных сообщений. 
  Protected NewLen 
  
  NewLen=NetBuff_ReallocateMemory(*Buff, AddBytes) ; Выделение памяти 
  If NewLen>0 And *Buff\Len >= AddBytes+*Buff\Pos ; Память выделена 
    CopyMemory(*Mem, *Buff\Buff+*Buff\Pos, AddBytes) 
    *Buff\Pos + AddBytes 
  EndIf 
  
EndProcedure 
 
 
Procedure NetBuff_DelMem(*Buff.NetBuff_Param, DelBytes) ; Удаление принятых данных, из памяти после успешной обработки сообщения. 
  
  If *Buff\Buff 
    If *Buff\Pos <= DelBytes 
      *Buff\Pos = 0 
    Else 
      If *Buff\Pos>DelBytes 
        MoveMemory(*Buff\Buff+DelBytes, *Buff\Buff, *Buff\Pos-DelBytes) ; 
      EndIf 
      *Buff\Pos - DelBytes 
      If *Buff\Pos<0 
        *Buff\Pos=0 
      EndIf 
    EndIf 
  EndIf 
  
EndProcedure 
 
 
Enumeration ; Поддерживаемые команды (поле "Type" структуры).
  #NetPacketType_EndProg ; Завершить работу клиента.
  #NetPacketType_Data    ; Данные.
EndEnumeration 
 
Structure NetPacket_Header 
  Size.u 
  Type.u 
EndStructure 
 
Structure NetPacket_EndData 
  Header.NetPacket_Header 
EndStructure 
 
Structure NetPacket_Data 
  Header.NetPacket_Header 
  Buff.a[0] 
EndStructure 
 
 
Procedure Net_InData(Connect, *Point, Size, *BuffInfo.NetBuff_Param) 
  Protected InBytes, *Header.NetPacket_Header 
  Protected Result 
  
  NetBuff_AddMem(*BuffInfo, *Point, Size) 
  Result = #False 
  
  Repeat 
    
    If *BuffInfo\Pos>=SizeOf(NetPacket_Header) 
      
      *Header = *BuffInfo\Buff 
      
      If *BuffInfo\Pos >= *Header\Size 
        
        Select *Header\Type 
          Case #NetPacketType_EndProg 
            Protected *EndData.NetPacket_EndData = *BuffInfo\Buff 
            
            Result = #True 
            
            NetBuff_DelMem(*BuffInfo, *Header\Size) 
            
          Case #NetPacketType_Data 
            Protected *|/1/>Data.NetPacket_Data = *BuffInfo\Buff 
            
            Debug PeekS(@*|/1/>Data\Buff[0], *|/1/>Data\Header\Size-OffsetOf(NetPacket_Data\Buff)) 
            
            NetBuff_DelMem(*BuffInfo, *Header\Size) 
            
            
        EndSelect 
        
      Else 
        Break 
      EndIf 
      
    EndIf 
    
  Until *BuffInfo\Pos < SizeOf(NetPacket_Header) 
  
  ProcedureReturn Result 
  
EndProcedure 
 
InitNetwork() 
 
Define Connect = OpenNetworkConnection("127.0.0.1", 2222, #PB_Network_TCP) 
If Connect 
  
  Define *Point = AllocateMemory(65536) 
  If *Point 
    Define BuffInfo.NetBuff_Param\Buff = AllocateMemory(10) 
    BuffInfo\Len=10 
    BuffInfo\Pos=0 
    If BuffInfo\Buff 
      
      Repeat 
        Define NetEvent = NetworkClientEvent(Connect) 
        If NetEvent = #PB_NetworkEvent_Data 
          Define InBytes = ReceiveNetworkData(Connect, *Point, 65536) 
          If Net_InData(Connect, *Point, InBytes, @BuffInfo) 
            Break 
          EndIf 
        Else 
          Delay(10) 
        EndIf 
      ForEver 
      
      CloseNetworkConnection(Connect) 
      
      FreeMemory(BuffInfo\Buff) 
    EndIf 
    FreeMemory(*Point) 
  EndIf 
Else 
  Debug "Нет связи" 
EndIf

@CAMOKPYT · 15.09.2013, 04:48

просто создайте UDP\TCP сокет на любом ЯП и парсите слушаемый\отправляемый буфер как строку

@агерон · 15.09.2013, 05:00

решу поправить, не как строку а как массив байт, поток байт, т. к. в С/C++ строки оканчиваются нулем, а после этого нуля также могут идти данные

@CAMOKPYT · 15.09.2013, 05:29

Сообщение от агерон

решу поправить, не как строку а как массив байт, поток байт, т. к. в С/C++ строки оканчиваются нулем, а после этого нуля также могут идти данные

конечно поток байт, но для простого протокола удобнее чтобы буфер было однородным, например парсить поток байт как массив однобайтовых char и получать строку на выходе, поправьте если не прав)

@fklm1994 · 26.10.2013, 15:13 **[ТС]**

Спасибо большое за ваши подсказки! К сожалению, за данный проект смог взяться совсем недавно. Как язык программирования был выбран Python 3.3. Как думаете, есть ли смысл сделать протокол, аналогичный Telnet, а для передачи данных использовать аналог TFTP? Так сказать, сделать некий гибрид. Или же лучше присмотреться к другим протоколам передачи данных?

@mikello · 16.02.2019, 13:34

locm, здравствуйте

После Вашего сообщения появилась парочка вопросов =) Ответьте, если можете.

1.
1) Есть реализация для протокола прикладного уровня, работающего поверх TCP/UDP (Ваш пример)

2) Есть программа, которая работает на TCP/UDP протоколе. (например клиент-сервер UDP)

Чем они отличаются, с точки зрения программирования (программиста)? Насколько я понимаю, в первом случае мы имеем дело с передаваемой структурированной информацией (как в Вашем примере), а во втором - нет.

2.Где в Вашем коде (клиент/сервер) участки, которые соответствуют "описанию протокола" (служебным сообщениям, которые описаны - keep-alive, choke и т.д.)?

@locm · 16.02.2019, 16:48

Это одна из реализаций протокола. Она не обязательно должна быть такой.
Если посмотреть существующие протоколы, то они могут быть похожи на приведенный мной, так и сильно от него отличаться.

@mikello · 15.05.2019, 20:16

locm, здравствуйте.

У меня к Вам такой вопрос - у Вас в коде сервера и клиента есть функции для работы с сетью, т.е. по сути Ваш протокол занимается передачей данных по сети?

(Вопрос такой возник, т.к. вот тут - http://www.netpatch.ru/arch/mi... lava1.html , сказано, что Существует еще одно отличие между прикладным уровнем и тремя нижними уровнями. Прикладной уровень обычно является приложением и взаимодействует с пользователем, а не занимается передачей данных по сети. Три нижних уровня ничего не знают о работающих над ними приложениях, однако отвечают за все детали коммуникаций.)

@locm · 16.05.2019, 00:26

Функции передачи через сеть можно заменить например на передачу через COM порт или другой интерфейс.

@mikello · 16.05.2019, 23:00

locm,

Ок, я видимо не совсем корректно сформулировал вопрос.

Возможно ли создать протокол прикладного уровня, но так, чтобы за передачу данных по сети отвечала реализация протокола TCP, встроенная в ядро ОС?

@Usaga · 17.05.2019, 07:47

mikello, а оно сейчас не так разве? На основе TCP вообще нет никаких прикладных протоколов типа HTTP и FTP?

@mikello · 17.05.2019, 14:30

Usaga, именно так. Но непонятно другое - в протоколе HTTP используются функции для работы с сетью (как в примере выше) или там по-другому происходит обращение к протоколу TCP ?

@Usaga · 17.05.2019, 15:55

mikello, работа с TCP всегда происходит одним и тем же образом: последовательное подсовывание данных на отправку и такое же чтение.

Добавлено через 7 минут
Как примерно это происходит вы можете посмотреть в этой статье: https://m.habr.com/ru/company/... og/423105/

Там пример на С#, но смысл тот-же на любом языке с незначительными отличиями.

@mikello · 17.01.2020, 23:44

locm, Здравствуйте!=)

Недавно мне пришлось столкнуться с более подробным изучением работы протоколов TCP/IP. В связи с некоторыми моментами вспомнил Ваш пост (https://www.cyberforum.ru/post5041232.html), а именно:

"Но это нежелательно, поскольку если потеряется пакет не большого размера, то его быстрее можно будет повторно отправить."

Не совсем понятно, как может потеряться большой пакет целиком (например 1Гб), если он в процессе передачи будет дробиться на мелкие фрагменты? То есть, если я правильно понимаю, могут потеряться какие-то фрагменты, но не весь пакет и в случае с TCP эти фрагменты будут переотправлены.

@mikello · 17.01.2020, 23:44

locm, Здравствуйте!=)

Недавно мне пришлось столкнуться с более подробным изучением работы протоколов TCP/IP. В связи с некоторыми моментами вспомнил Ваш пост (https://www.cyberforum.ru/post5041232.html), а именно:

"Но это нежелательно, поскольку если потеряется пакет не большого размера, то его быстрее можно будет повторно отправить."

Не совсем понятно, как может потеряться большой пакет целиком (например 1Гб), если он в процессе передачи будет дробиться на мелкие фрагменты? То есть, если я правильно понимаю, могут потеряться какие-то фрагменты, но не весь пакет и в случае с TCP эти фрагменты будут переотправлены.

@locm · 18.01.2020, 02:31

TCP это протокол с гарантированной доставкой данных. В данном случае реализован другой протокол поверх TCP.
Даже в этом случае возможна потеря данных, скажем было прерывание по таймауту (вовремя не пришли данные) или соединение разорвано.

Новые блоги и статьи Все статьи Все блоги /
Access VikBal 11.12.2025 Помогите пожалуйста !! Как объединить 2 одинаковые БД Access с разными данными.	Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro	Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .	Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .
Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .	Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .	Мысли в слух kumehtar 18.11.2025 Кстати, совсем недавно имел разговор на тему медитаций с людьми. И обнаружил, что они вообще не понимают что такое медитация и зачем она нужна. Самые базовые вещи. Для них это - когда просто люди. . .	Создание Single Page Application на фреймах krapotkin 16.11.2025 Статья исключительно для начинающих. Подходы оригинальностью не блещут. В век Веб все очень привыкли к дизайну Single-Page-Application . Быстренько разберем подход "на фреймах". Мы делаем одну. . .	Фото: Daniel Greenwood kumehtar 13.11.2025

@fklm1994 0 / 0 / 0 Регистрация: 15.06.2013 Сообщений: 6

	Создание протокола прикладного уровня 08.09.2013, 01:26. Показов 15810. Ответов 17 Метки нет (Все метки) Доброго времени суток, форумчане! Недавно решил поставить себе цель написать собственный протокол прикладного уровня. Протокол хочу использовать для передачи данных через сеть(как медиафайлы, так и какие либо команды). Имею примерное представление того, как будет выглядеть отсылаемый пакет данных, но, к сожалению, не знаю какой язык использовать и как, примерно, это всё реализуется. Буду при знателен, если вы меня подталкнёте в правильное русло. 0

raxper 10236 / 6614 / 498 Регистрация: 28.12.2010 Сообщений: 21,154 Записей в блоге: 1
	08.09.2013, 13:55
	...язык по сути не важен. Начните с изучения простых и известных протоколов поверх TCP/IP. Рекомендую почитать http://cnp3book.info.ucl.ac.be/ 0

@CAMOKPYT 10 / 10 / 0 Регистрация: 16.01.2013 Сообщений: 37
	15.09.2013, 04:48
	просто создайте UDP\TCP сокет на любом ЯП и парсите слушаемый\отправляемый буфер как строку 0

@агерон 447 / 300 / 65 Регистрация: 12.10.2009 Сообщений: 1,162
	15.09.2013, 05:00
	решу поправить, не как строку а как массив байт, поток байт, т. к. в С/C++ строки оканчиваются нулем, а после этого нуля также могут идти данные 1

@fklm1994 0 / 0 / 0 Регистрация: 15.06.2013 Сообщений: 6
	26.10.2013, 15:13 [ТС]
	Спасибо большое за ваши подсказки! К сожалению, за данный проект смог взяться совсем недавно. Как язык программирования был выбран Python 3.3. Как думаете, есть ли смысл сделать протокол, аналогичный Telnet, а для передачи данных использовать аналог TFTP? Так сказать, сделать некий гибрид. Или же лучше присмотреться к другим протоколам передачи данных? 0

@mikello 57 / 48 / 5 Регистрация: 19.11.2017 Сообщений: 857
	16.02.2019, 13:34
	locm, здравствуйте После Вашего сообщения появилась парочка вопросов =) Ответьте, если можете. 1. 1) Есть реализация для протокола прикладного уровня, работающего поверх TCP/UDP (Ваш пример) 2) Есть программа, которая работает на TCP/UDP протоколе. (например клиент-сервер UDP) Чем они отличаются, с точки зрения программирования (программиста)? Насколько я понимаю, в первом случае мы имеем дело с передаваемой структурированной информацией (как в Вашем примере), а во втором - нет. 2.Где в Вашем коде (клиент/сервер) участки, которые соответствуют "описанию протокола" (служебным сообщениям, которые описаны - keep-alive, choke и т.д.)? 0

@locm 6498 / 3128 / 331 Регистрация: 28.10.2011 Сообщений: 12,297 Записей в блоге: 7
	16.02.2019, 16:48
	Это одна из реализаций протокола. Она не обязательно должна быть такой. Если посмотреть существующие протоколы, то они могут быть похожи на приведенный мной, так и сильно от него отличаться. 1

@mikello 57 / 48 / 5 Регистрация: 19.11.2017 Сообщений: 857
	15.05.2019, 20:16
	locm, здравствуйте. У меня к Вам такой вопрос - у Вас в коде сервера и клиента есть функции для работы с сетью, т.е. по сути Ваш протокол занимается передачей данных по сети? (Вопрос такой возник, т.к. вот тут - http://www.netpatch.ru/arch/mi... lava1.html , сказано, что Существует еще одно отличие между прикладным уровнем и тремя нижними уровнями. Прикладной уровень обычно является приложением и взаимодействует с пользователем, а не занимается передачей данных по сети. Три нижних уровня ничего не знают о работающих над ними приложениях, однако отвечают за все детали коммуникаций.) 0

@locm 6498 / 3128 / 331 Регистрация: 28.10.2011 Сообщений: 12,297 Записей в блоге: 7
	16.05.2019, 00:26
	Функции передачи через сеть можно заменить например на передачу через COM порт или другой интерфейс. 1

@mikello 57 / 48 / 5 Регистрация: 19.11.2017 Сообщений: 857
	16.05.2019, 23:00
	locm, Ок, я видимо не совсем корректно сформулировал вопрос. Возможно ли создать протокол прикладного уровня, но так, чтобы за передачу данных по сети отвечала реализация протокола TCP, встроенная в ядро ОС? 0

@Usaga 14078 / 9295 / 1347 Регистрация: 21.01.2016 Сообщений: 34,895
	17.05.2019, 07:47
	mikello, а оно сейчас не так разве? На основе TCP вообще нет никаких прикладных протоколов типа HTTP и FTP? 1

@mikello 57 / 48 / 5 Регистрация: 19.11.2017 Сообщений: 857
	17.05.2019, 14:30
	Usaga, именно так. Но непонятно другое - в протоколе HTTP используются функции для работы с сетью (как в примере выше) или там по-другому происходит обращение к протоколу TCP ? 0

@Usaga 14078 / 9295 / 1347 Регистрация: 21.01.2016 Сообщений: 34,895
	17.05.2019, 15:55
	mikello, работа с TCP всегда происходит одним и тем же образом: последовательное подсовывание данных на отправку и такое же чтение. Добавлено через 7 минут Как примерно это происходит вы можете посмотреть в этой статье: https://m.habr.com/ru/company/... og/423105/ Там пример на С#, но смысл тот-же на любом языке с незначительными отличиями. 1

@locm 6498 / 3128 / 331 Регистрация: 28.10.2011 Сообщений: 12,297 Записей в блоге: 7
	18.01.2020, 02:31
	TCP это протокол с гарантированной доставкой данных. В данном случае реализован другой протокол поверх TCP. Даже в этом случае возможна потеря данных, скажем было прерывание по таймауту (вовремя не пришли данные) или соединение разорвано. 1