--------------------------------------------------------------------------------
unisock.h остался без изменений:
--------------------------------------------------------------------------------

#ifndef _UNISOCK_H_

#ifndef _WIN32

#include <sys/types.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <netinet/in.h>
#include <netdb.h>
#include <unistd.h>

typedef int SOCKET;
typedef struct sockaddr SOCKADDR;
typedef struct sockaddr_in SOCKADDR_IN;

#define SOCKET_ERROR -1
#define INVALID_SOCKET -1

#define SD_RECEIVE 0x0
#define SD_SEND 0x1
#define SD_BOTH 0x2

#define closesocket(s) close(s)

#endif /* _WIN32 */

#define _UNISOCK_H_
#endif /* _UNISOCK_H_ */


--------------------------------------------------------------------------------

В этом примере мы устанавливаем соединение с нашим сервером, дожидаемся приветствия, посылаем ответное и закрываем соединение. Напомним, что recv(2) является блокирующим вызовом, что нас, вообще говоря, не устраивает. Тем не менее, мы снова можем перевести наш сокет в неблокирующее состояние и воспользоваться select. Мы так и поступим в дальнейшем, а этот пример просто показывает технику написания простейшего клиента, и мы с удовольствием обнаруживаем, что это не слишком сложно. В завершение обратим внимание на вызовы inet_addr(3) и htons(3). Первая функция дает IP-адрес по символьному его представлению, а вторая переводит short int в целое с порядком байтов, принятых в сети. Часто этот порядок совпадает с порядком байтов в машинном представлении, но может и не совпадать (имеется ввиду т. н. LSB и FSB представления). Впрочем, это уже тонкости, о которых можно почитать и в другом месте . И наконец, можно на досуге взглянуть на функцию gethostbyname(3), которая выполняет т. н. разрешение (resolving) по имени хоста. Используя ее, мы могли бы обратиться к нашему серверу не по IP-адресу, а по его имени ("localhost").

Глава 3 Заключение.
Итак, в данной статье мы выяснили, как обращаться с сокетами. Те, кто уже имел с ними дело (и набрался терпения дочитать до этого места), наверное обратили внимание на то, что мы использовали "классическую" Берклиевскую реализацию. Она хороша тем, что в большинстве случаев переносима между платформами, однако нам бы не хотелось подталкивать разработчиков к использованию именно такого подхода, тем более, что, как мы в дальнейшем увидим, для работы с SMS-протоколами это совсем необязательно, ибо они абстрагированы от деталей установки соединения. Например, те, кто программирует под Windows, могут воспользоваться функциями из семейства WSA* (если, конечно, не уснут, читая их перечень , а программисты, привыкшие работать с MFC, возможно найдут полезным класс CSocket (правда, если Вы собираетесь использовать его в мультипоточном приложении с CWinThread, не забудьте включить заклинание:


--------------------------------------------------------------------------------

#ifndef _AFXDLL
#define _AFX_SOCK_THREAD_STATE AFX_MODULE_THREAD_STATE
#define _afxSockThreadState AfxGetModuleThreadState()

_AFX_SOCK_THREAD_STATE* pState = _afxSockThreadState;
if (pState->m_pmapSocketHandle == NULL)
pState->m_pmapSocketHandle = new CMapPtrToPtr;
if (pState->m_pmapDeadSockets == NULL)
pState->m_pmapDeadSockets = new CMapPtrToPtr;
if (pState->m_plistSocketNotifications == NULL)
pState->m_plistSocketNotifications = new CPtrList;

#endif


--------------------------------------------------------------------------------
в код thread'а до самой первой сокетной операции; возможно, это сэкономит Вам выходные . И, в конце концов, Вы можете воспользоваться компонентами (Привет, Михаил! , которых достаточно много и которые достаточно "бросить" на форму, особенно это касается поклонников продуктов от Borland.

автор С. Кадаков sgerr@hotmail.com