4. Модель сервера приложений

Модель сервера приложений (Application Server, AS) является расширением двухуровневой модели и в ней вводится дополнительный промежуточный уровень между клиентом и сервером. Архитектура трехуровневой модели приведена на рис. 8. Этот промежуточный уровень содержит один или несколько серверов приложений.

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

Нужно отметить, что эта модель обладает большей гибкостью, чем двухуровневые модели. Наиболее заметны преимущества модели сервера приложений в тех случаях, когда клиенты выполняются сложные аналитические расчеты над базой данных, которые относятся в области OLAP-приложений (On-line analytical processing). В этой модели большая часть бизнес-логики клиента изолирована от возможностей расширенного SQL, реализованного в конкретной СУБД, и может быть выполнена на стандартных языках программирования, таких как C, C++, Object Pascal, Java. Это повышает переносимость системы, ее масштабируемость.

7

Процессом обычно называют экземпляр выполняемой программы.

Процессы инертны. Отвечают же за исполнение кода, содержащегося в адресном пространстве процесса, потоки. Поток (thread) - некая сущность внутри процесса, получающая процессорное время для выполнения. В каждом процессе есть минимум один поток.

Не надо терминологию смешивать. :) Нить - это thread(дословно). В русском варианте принято называть ее так же потоком. То есть то, что мы называем потоком, который выполняет код - это thread(нить). Тот что на самом деле поток(stream) ассоциируется в оригинальной терминологии с потоками данных. По русски мы называем это потоком тоже. Fiber(волокно) - это действительно то, во что можно превратить нить(thread), для создания корпоротивных потоков выполнения. То есть, fibers - это потоки которые сами переключают между собой время выполнения(как и было сказано Adil'ом). Используются редко.

поток (thread) может иметь несколько нитей (fiber). Основная разница между ними - то что потоки переключаются (забирают процессорное время на исполнение) виндосами, а нити потока надо переключать самому ( в коде, ест-но)

8

class Thread

Создает и контролирует поток, задает приоритет и возвращает статус.

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

В течение своего существования поток всегда находится в одном или более состояниях, определенных в классе ThreadState. Для потока можно запрашивать планирование уровня приоритета, который определяется классом ThreadPriority, но не гарантируется, что операционная система предоставит его.

using System;

using System.Threading;

// Simple threading scenario: Start a static method running

// on a second thread.

public class ThreadExample {

// The ThreadProc method is called when the thread starts.

// It loops ten times, writing to the console and yielding

// the rest of its time slice each time, and then ends.

public static void ThreadProc() {

for (int i = 0; i < 10; i++) {

Console.WriteLine("ThreadProc: {0}", i);

// Yield the rest of the time slice.

Thread.Sleep(0);

}

}

public static void Main() {

Console.WriteLine("Main thread: Start a second thread.");

// The constructor for the Thread class requires a ThreadStart

// delegate that represents the method to be executed on the

// thread. C# simplifies the creation of this delegate.

Thread t = new Thread(new ThreadStart(ThreadProc));

// Start ThreadProc. Note that on a uniprocessor, the new

// thread does not get any processor time until the main thread

// is preempted or yields. Uncomment the Thread.Sleep that

// follows t.Start() to see the difference.

t.Start();

//Thread.Sleep(0);

for (int i = 0; i < 4; i++) {

Console.WriteLine("Main thread: Do some work.");

Thread.Sleep(0);

}

Console.WriteLine("Main thread: Call Join(), to wait until ThreadProc ends.");

t.Join();

Console.WriteLine("Main thread: ThreadProc.Join has returned. Press Enter to end program.");

Console.ReadLine();

}

}

Main thread: Start a second thread.Main thread: Do some work.ThreadProc: 0

Main thread: Do some work.ThreadProc: 1

Main thread: Do some work.ThreadProc: 2

Main thread: Do some work.ThreadProc: 3

Main thread: Call Join(), to wait until ThreadProc ends.ThreadProc: 4

ThreadProc: 5

ThreadProc: 6

ThreadProc: 7

ThreadProc: 8

ThreadProc: 9

Main thread: ThreadProc.Join has returned.Press Enter to end program.

Данный тип потокобезопасен.

9,10,11,12,13,14

Потоковая безопасность (англ. thread-safety) — это концепция программирования, применимая к многопоточным программам. Код потоково-безопасный, если он функционирует корректно при использовании из нескольких потоков одновременно. В частности, он должен обеспечивать корректный доступ нескольких потоков к разделяемым данным.

В общем случае потоковая безопасность сложно устанавливается. Но существует несколько источников выявления нарушений потоковой безопасности:

• доступ к глобальным переменным или динамической памяти (куче);

• выделение/освобождение ресурсов, имеющих глобальные ограничения (файлы, процессы и др.);

• неявный доступ через ссылки и указатели;

• побочный эффект функций;

Есть несколько способов достигнуть потоковой безопасности:

Реентерабельность 

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

Линеаризуемость 

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

Нитебезопасный код (линии)

Семафо́р — объект, позволяющий войти в заданный участок кода не более чем n потокам.

Операции: inc, dec.

Вот некоторые из проблем, которые могут решать семафоры.

• запрет одновременного выполнения заданных участков кода;

• поочерёдный доступ к критическому ресурсу (важному ресурсу, для которого невозможен одновременный доступ).

• using System;

• using System.Threading;

• public class Example

• {

• // A semaphore that simulates a limited resource pool.

• //

• private static Semaphore _pool;

• // A padding interval to make the output more orderly.

• private static int _padding;

• public static void Main()

• {

• // Create a semaphore that can satisfy up to three

• // concurrent requests. Use an initial count of zero,

• // so that the entire semaphore count is initially

• // owned by the main program thread.

• //

• _pool = new Semaphore(0, 3);

• // Create and start five numbered threads.

• //

• for(int i = 1; i <= 5; i++)

• {

• Thread t = new Thread(new ParameterizedThreadStart(Worker));

• // Start the thread, passing the number.

• //

• t.Start(i);

• }

• // Wait for half a second, to allow all the

• // threads to start and to block on the semaphore.

• //

• Thread.Sleep(500);

• // The main thread starts out holding the entire

• // semaphore count. Calling Release(3) brings the

• // semaphore count back to its maximum value, and

• // allows the waiting threads to enter the semaphore,

• // up to three at a time.

• //

• Console.WriteLine("Main thread calls Release(3).");

• _pool.Release(3);

• Console.WriteLine("Main thread exits.");

• }

• private static void Worker(object num)

• {

• // Each worker thread begins by requesting the

• // semaphore.

• Console.WriteLine("Thread {0} begins " +

• "and waits for the semaphore.", num);

• _pool.WaitOne();

• // A padding interval to make the output more orderly.

• int padding = Interlocked.Add(ref _padding, 100);

• Console.WriteLine("Thread {0} enters the semaphore.", num);

• // The thread's "work" consists of sleeping for

• // about a second. Each thread "works" a little

• // longer, just to make the output more orderly.

• //

• Thread.Sleep(1000 + padding);

• Console.WriteLine("Thread {0} releases the semaphore.", num);

• Console.WriteLine("Thread {0} previous semaphore count: {1}",

• num, _pool.Release());

• }

• }

Мью́текс (англ. mutex, от mutual exclusion — взаимное исключение) — одноместный семафор, служащий в программировании для синхронизации одновременно выполняющихся потоков.

Мьютексы (mutex) — это один из вариантов семафорных механизмов для организации взаимного исключения. Они реализованы во многих ОС, их основное назначение — организация взаимного исключения для потоков из одного и того же или из разных процессов.

Мьютексы — это простейшие двоичные семафоры, которые могут находиться в одном из двух состояний — отмеченном или неотмеченном (открыт и закрыт соответственно). Когда какой-либо поток, принадлежащий любому процессу, становится владельцем объекта mutex, последний переводится в неотмеченное состояние. Если задача освобождает мьютекс, его состояние становится отмеченным.

Задача мьютекса — защита объекта от доступа к нему других потоков, отличных от того, который завладел мьютексом. В каждый конкретный момент только один поток может владеть объектом, защищённым мьютексом. Если другому потоку будет нужен доступ к переменной, защищённой мьютексом, то этот поток засыпает до тех пор, пока мьютекс не будет освобождён.

Цель использования мьютексов — защита данных от повреждения; однако им порождаются другие проблемы, такие как взаимная блокировка (клинч) и «соревнование за ресурс».

Мьютекс отличается от спинлока наличием очереди ожидающих потоков.

msdn:

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

Можно использовать метод WaitHandle.WaitOne для запроса на владение семафором. Поток, владеющий семафором, может запрашивать его в повторяющихся вызовах WaitOne без блокировки выполнения. Однако поток должен вызвать метод ReleaseMutex соответственное количество раз для того, чтобы прекратить владеть семафором. Класс Mutex выполняет идентификацию потоков, таким образом, мьютекс может освобождаться только потоком, получившим его. Напротив, класс Semaphore не обеспечивает потоковой идентификации.

Если поток завершается, владея мьютексом, то мьютекс называется брошенным. Состояние мьютекса задается сигнальным, и мьютекс переходит во владение следующему ожидающему потоку. Начиная с версии 2.0 платформы .NET Framework, в следующем потоке, получившем брошенный мьютекс, выдается исключение AbandonedMutexException. В версиях платформы .NET Framework 2.0 и более ранних исключение не выдавалась.

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

Мьютексы бывают двух типов: локальные мьютексы (без имени), и именованные системные мьютексы. Локальный мьютекс существует только внутри одного процесса. Он может использоваться любым потоком в процессе, который содержит ссылку на объект Mutex, представляющий мьютекс. Каждый неименованный объект Mutex представляет отдельный локальный мьютекс.

Именованные системные мьютексы доступны в пределах всей операционной системы и могут быть использованы для синхронизации действий процессов. Можно создать объект Mutex, представляющий именованный системный мьютекс, используя конструктор с поддержкой имен. Объект операционной системы может быть создан в то же время, или существовать до создания объекта Mutex. Можно создать несколько объектов Mutex, представляющих один и тот же именованный системный мьютекс, и использовать метод OpenExisting для открытия существующего именованного системного мьютекса.

// This example shows how a Mutex is used to synchronize access

// to a protected resource. Unlike Monitor, Mutex can be used with

// WaitHandle.WaitAll and WaitAny, and can be passed across

// AppDomain boundaries.

using System;

using System.Threading;

class Test

{

// Create a new Mutex. The creating thread does not own the

// Mutex.

private static Mutex mut = new Mutex();

private const int numIterations = 1;

private const int numThreads = 3;

static void Main()

{

// Create the threads that will use the protected resource.

for(int i = 0; i < numThreads; i++)

{

Thread myThread = new Thread(new ThreadStart(MyThreadProc));

myThread.Name = String.Format("Thread{0}", i + 1);

myThread.Start();

}

// The main thread exits, but the application continues to

// run until all foreground threads have exited.

}

private static void MyThreadProc()

{

for(int i = 0; i < numIterations; i++)

{

UseResource();

}

}

// This method represents a resource that must be synchronized

// so that only one thread at a time can enter.

private static void UseResource()

{

// Wait until it is safe to enter.

mut.WaitOne();

Console.WriteLine("{0} has entered the protected area",

Thread.CurrentThread.Name);

// Place code to access non-reentrant resources here.

// Simulate some work.

Thread.Sleep(500);

Console.WriteLine("{0} is leaving the protected area\r\n",

Thread.CurrentThread.Name);

// Release the Mutex.

mut.ReleaseMutex();

}

}

Критическая секция (англ. critical section) — объект синхронизации потоков, позволяющий предотвратить одновременное выполнение некоторого набора операций (обычно связанных с доступом к данным) несколькими потоками. Критическая секция выполняет те же задачи, что и мьютекс.

Между мьютексом и критической секцией есть терминологические различия, так процедура, аналогичная захвату мьютекса, называется входом в критическую секцию (англ. enter), снятию блокировки мьютекса — выходом из критической секции (англ. leave).

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

В операционных системах семейства Microsoft Windows разница между мьютексом и критической секцией в том, что мьютекс является объектом ядра и может быть использован несколькими процессами одновременно, критическая секция же принадлежит процессу и служит для синхронизации только его потоков.

Критические секции Windows имеют оптимизацию, заключающуюся в использовании атомарно изменяемой переменной наряду с объектом «событие синхронизации» ядра. Захват критической секции означает атомарное увеличение переменной на 1. Переход к ожиданию на событии ядра осуществляется только в случае, если значение переменной до захвата было уже больше 1, то есть есть реальное «соревнование» двух или более потоков за ресурс.

Таким образом, при отсутствии соревнования захват/освобождение критической секции обходятся без обращений к ядру.

Кроме того, захват уже занятой критической секции до обращения к ядру какое-то небольшое время (англ. spin count) ждёт в цикле опроса переменной, и, если переменная становится равной 0, то захват происходит без обращений к ядру.

Сходный объект в ядре Windows называется FAST_MUTEX (ExAcquire/ReleaseFastMutex). Он отличается от критической секции отсутствием поддержки рекурсивного повторного захвата тем же потоком.

Аналогичный объект в Linux называется фьютекс.

События:

2 состояния (true-false)

2 операции (set-reset, wait-pulse)

Пожалуй, самый простой и фундаментальный синхронизирующий объект. Это всего лишь флаг, которому функциями SetEvent/ResetEvent можно задать состояние: сигнализирующее или нейтральное. Событие – это самый удобный способ передать сигнал ожидающему потоку, что некое событие свершилось (потому оно так и называется), и можно продолжать работу. С помощью события мы легко решим проблему синхронизации при инициализации рабочего потока:

15,16

Pipes (PIPE - расширение понятия конвейера в Unix и подобных ОС, один из методов межпроцессного взаимодействия. Это понятие также существует и в Microsoft Windows, хотя там его семантика существенно отличается. Традиционный канал — «безымянен», потому что существует анонимно и только во время выполнения процесса. Именованный канал — существует в системе и после завершения процесса. Он должен быть «отсоединён» или удалён когда уже не используется. Процессы обычно подсоединяются к каналу для осуществления взаимодействия между процессами.

System.IO.Pipes;

Stream s = new NamedPipeServerStream(“megapipe”, PipeDirection.InOut, PipeTransmissionMode.Message, PipeOption.Asynchronous);

Stream ss = new NamedPipeClientStream(“.”, “megapipe”, PipeDirection.InOut, PipeOption.Asynchronous, System.Security.Principal. Tokenimpersonationlevel.None, );

В Windows дизайн именованных каналов смещён к взаимодействию «клиент-сервер», и они работают во многом как сокеты: помимо обычных операций чтения и записи, именованные каналы в Windows поддерживают явный «пассивный» режим для серверных приложений (для сравнения: Unix domain socket). Windows 95 поддерживает клиенты именованных каналов, а системы ветви Windows NT могут служить также и серверами.

К именованному каналу можно обращаться в значительной степени как к файлу. Можно использовать функции Windows API CreateFile, CloseHandle, ReadFile, WriteFile, чтобы открывать и закрывать канал, выполнять чтение и запись. Функции стандартной библиотеки Си такие как fopen, fread, fwrite и fclose, тоже можно использовать, в отличие от сокетов Windows (англ.), которые не реализуют использование стандартных файловых операций в сети. Интерфейс командной строки (как в Unix) отсутствует.

Именованные каналы — не существуют постоянно и не могут, в отличие от Unix, быть созданы как специальные файлы в произвольной доступной для записи файловой системе, но имеют временные имена (освобождаемые после закрытия последней ссылки на них), которые выделяются в корне файловой системы именованных каналов (англ. named pipe filesystem, NPFS) и монтируются по специальному пути «\\.\pipe\» (т. е. у канала под названием «foo» полное имя будет «\\.\pipe\foo»). Анонимные каналы, использующиеся в конвейерах — это на самом деле именованные каналы со случайным именем.

Именованные каналы обычно не доступны непосредственно пользователю, но есть существенные исключения. Например, средство виртуализации рабочих станций VMWare может открывать эмулируемый последовательный порт для главной системы как именованный канал, а отладчик уровня ядра kd от Microsoft поддерживает именованные каналы в качестве средства сообщения при отладке (фактически, так как kd обычно требует подключения к целевому компьютеру по последовательному порту, VMware и kd можно соединить вместе для отладки драйверов устройств на одном компьютере). Обе программы требуют от пользователя указания имён канала в виде «\\.\pipe\имя».

Именованные каналы в Windows NT могут наследовать контекст безопасности.)

Shared memory (Плюсы – быстрота, Минусы – требуется синхронизация, нельзя положить указатель.

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

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

Примерный сценарий использования разделяемой памяти при реализации технологий «клиент—сервер» имеет вид:

1. сервер получает доступ к разделяемой памяти, используя какафор;

2. сервер производит запись данных в разделяемую память;

3. после завершения записи данных сервер освобождает доступ к разделяемой памяти с помощью семафора;

4. клиент получает доступ к разделяемой памяти, запирая доступ к этой памяти для других процессов с помощью семафора;

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

Для работы с разделяемой памятью используются системные вызовы:

• shmget — создание сегмента разделяемой памяти;

• shmctl — установка параметров;

• shmat — подсоединение сегмента памяти;

• shmdt — отсоединение сегмента.

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

Message queue

Memory mapped files (отображенный в памяти файл)

Socket

17

Предоставляет Stream в именованном канале, поддерживая синхронные и асинхронные операции чтения и записи.

Именованные каналы представляют собой односторонние или дуплексные каналы связи между сервером канала и одним или несколькими клиентами канала. Именованные каналы можно использовать для локального взаимодействия между процессами или в масштабе сети. Одно имя канала может быть присвоено нескольким объектам NamedPipeClientStream.

Любой процесс может выступать и в качестве сервера именованного канала, и в качестве клиента канала, и в обоих этих качествах.

Для Windows XP Professional и Windows 2000 Server одновременно могут подключиться по сети максимум 10 каналов.

В следующем примере показано, как отправить строку из родительского процесса в дочерний процесс на том же компьютере, используя именованные каналы. В этом примере создается объект NamedPipeServerStream в рамках родительского процесса со значением PipeDirection, равным Out. Затем сервер ждет, пока к нему подключится объект NamedPipeClientStream из дочернего процесса. В примере оба процесса выполняются на одном компьютере и для объекта NamedPipeClientStream в качестве PipeDirection задано In. Родительский процесс затем передает пользовательскую строку дочернему процессу. Эта строка выводится на консоль.

Данный пример относится к серверному процессу, в котором используется класс NamedPipeServerStream. Полный пример кода, включающий код клиента и код сервера канала, см. в разделе Практическое руководство. Использование именованных каналов для взаимодействия между процессами по сети.

Server:

using System;

using System.IO;

using System.IO.Pipes;

class PipeServer

{

static void Main()

{

using (NamedPipeServerStream pipeServer =

new NamedPipeServerStream("testpipe", PipeDirection.Out))

{

Console.WriteLine("NamedPipeServerStream object created.");

// Wait for a client to connect

Console.Write("Waiting for client connection...");

pipeServer.WaitForConnection();

Console.WriteLine("Client connected.");

try

{

// Read user input and send that to the client process.

using (StreamWriter sw = new StreamWriter(pipeServer))

{

sw.AutoFlush = true;

Console.Write("Enter text: ");

sw.WriteLine(Console.ReadLine());

}

}

// Catch the IOException that is raised if the pipe is broken

// or disconnected.

catch (IOException e)

{

Console.WriteLine("ERROR: {0}", e.Message);

}

}

}

}

Client:

using System;

using System.IO;

using System.IO.Pipes;

class PipeClient

{

static void Main(string[] args)

{

using (NamedPipeClientStream pipeClient =

new NamedPipeClientStream(".", "testpipe", PipeDirection.In))

{

// Connect to the pipe or wait until the pipe is available.

Console.Write("Attempting to connect to pipe...");

pipeClient.Connect();

Console.WriteLine("Connected to pipe.");

Console.WriteLine("There are currently {0} pipe server instances open.",

pipeClient.NumberOfServerInstances);

using (StreamReader sr = new StreamReader(pipeClient))

{

// Display the read text to the console

string temp;

while ((temp = sr.ReadLine()) != null)

{

Console.WriteLine("Received from server: {0}", temp);

}

}

}

Console.Write("Press Enter to continue...");

Console.ReadLine();

}

}

Любые открытые члены этого типа, объявленные как static (Shared в Visual Basic), являются потокобезопасными. Потокобезопасность членов экземпляров не гарантируется.

19,20,21,22

socket

тип сокета:

-SOCK_SREAM

*гарантия доставки (уведомление)

*сохраняется порядок пакетов

-SOCK_DGRAM (datagramm)

*нет гарантии доставки (уведомление)

*не сохраняется порядок пакетов

-SOCK_RAW (сетевой анализ (снифферы))

nfs (network file system)

пространство аресов (address family)

AF_UNIX

AF_INET

AF_XEROX -> IPX -> Novell (Netware)

AF_DECNET

API BSD Socket

Диаграмма состояний

SOCK_STREAM

server:

Socket() --> [unbinded] --> bind() --> [binded] --> listen() --> [listening] <--> accept -(new socket on server)-> [connected] --> send\recieve

|--> shudown() --> [incatvie] --> close()

client:

Socket() --> [unbinded] --> bind() --> [binded] --> connect() --> [connected] --> send\recieve

|--> --> --> --> -->| |--> shutdown()

SOCK_DGRAM

p2p

Socket() --> [unbinded] --> bind() --> [binded] --> sendto\recievefrom

|--> shutdown()

Socket:

int Socket(int AF, int type, inp proto);

AF:

AF_UNIX

AF_INET

...

type:

SOCK_DGRAM

SOCK_STREAM

...

AF_INET, SOCK_DGRAM: udp (universal dgram protocol)

AF_INET, SOCK_STREAM: tcp

bind:

struct sockaddr

{

short sa_AF; // 2 bytes

char sa_address[14];

};

struct sockaddr_in // internet

{

short sin_family; // AF_INET

ushort sin_port;

struct in_addr sin_addr;

}

int bind(int sock, sockaddr *address, int length);

/////

int sock = Socket(AF_INET, SOCK_STREAM, 0);

sockaddr_in addr;

addr.sin_family = AF_INET;

addr.sin_port = 80; // обратный порядок байтов (для совместимости со старыми программами)

addr.sin_port = htons(80); // host to short. (stoh, htonl, ltoh)

addr.sin_addr = wtf;

bind(sock, (sckaddr *)&addr, sizeof(addr));

listen

int listen(int sock, int maxb); // максимальный буфер запросов на соединение. maxb = 0 -> дефолтный буфер (не нулевой)

connect

int connect(inr sock, sockaddr *sa, int size);

accept

int accept(inr sock, sockaddr *sa, int size); // дескриптор сокета для нового клиента

send

int send(int sock, char *buf, int size, int flag); // возвращает число отосланных байтов

flag:

0 - default

MSG_OOB (out of bound)

recieve

int recv(int sock, char *buf, int size, int flag);

flag:

0

MSG_OOB

MSG_NOERROR

MSG_PEEK // top (не сдвигает указатель после считывания)

Thread Pool

Со́кеты (англ. socket — углубление, гнездо, разъём) — название программного интерфейса для обеспечения обмена данными между процессами. Процессы при таком обмене могут исполняться как на одной ЭВМ, так и на различных ЭВМ, связанных между собой сетью. Сокет — абстрактный объект, представляющий конечную точку соединения.

Следует различать клиентские и серверные сокеты. Клиентские сокеты грубо можно сравнить с оконечными аппаратами телефонной сети, а серверные — с коммутаторами. Клиентское приложение (например, браузер) использует только клиентские сокеты, а серверное (например, веб-сервер, которому браузер посылает запросы) — как клиентские, так и серверные сокеты.

Интерфейс сокетов впервые появился в BSD Unix. Программный интерфейс сокетов описан в стандарте POSIX.1 и в той или иной мере поддерживается всеми современными операционными системами.