Іноді мережні програми є рівноправними учасниками обміну інформацією. Не можна однозначно стверджувати, що одна програма обслуговує іншу. Однак у разі з TCP/IP розходження є більш чітке. Сервер прослуховує порт, щоби віднайти вхідні TCP-з’єднання або UDP-датаграми від одного чи декількох клієнтів. З іншого боку, можна вважати, що клієнт – це той, хто розпочинає діалог першим.
TCP – потоковий протокол і, хоча дані передаються в IP-пакетах, обсяг пакета прямо не є пов’язаний з кількістю даних, переданих TCP при виклику send. У приймального додатка немає надійного способу визначити, як саме дані розподілено по пакетах, оскільки поміж сусідніми викликами recv може надійти декілька пакетів. Отже, дані доставляються одержувачеві у вигляді потоку байтів, у якому немає понять “повідомлення” чи “межі повідомлення ”, тобто заздалегідь не є відомо, скільки байтів буде повернуто після звертання до функції читання.
Істотним є також час доставки повідомлень. Якщо програма-сервер перше повідомлення прочитає не відразу після його надіслання, а через певний час після того, як програма-клієнт надіслала друге, то будуть прочитані обидва повідомлення. Кількість даних, доступних додаткові в даний момент, — величина непевна.
Кількість даних, які повертаються внаслідок читання, є не передбачувана, тому програми мають бути готові до опрацювання цієї ситуації. З цього виходить, що важливим є визначення меж повідомлень і зреалізовувати їхнє збереження слід на прикладному рівні.
Найпростіший випадок — це повідомлення фіксованої довжини. У разі повідомлення фіксованої довжини потужні навантаження в мережі можуть призвести до надто великих затримок при обміні повідомлень і, як наслідок, —до “лавинного ефекту”.
Набули широкого розповсюдження два методи реалізації клієнт-серверної архітектури з повідомленнями змінної довжини. По-перше, можна розділяти запис спеціальними маркерами. У цьому разі використовують стандартну функцію fgets для розбивання потоку на рядки, за розділяч слугує символ нового рядка. Якщо маркер кінця запису зустрінеться в тілі повідомлення, то додаток-клієнт повинен попередньо знайти в повідомленні всі такі маркери й екранувати їх або закодувати якось ще, щоби приймаючий додаток не сприйняв їх помилково за завершення запису.
Приймальній стороні потрібно переглянути все повідомлення, вилучити символи екранування і віднайти розділячі записів. Оскільки при використанні маркерів завершення запису всі повідомлення слід переглядати двічі, цей метод краще застосовувати лише за наявності «природного» розділяча, наприклад символа нового рядка, котрий розділяє рядки тексту.
Інший метод роботи з повідомленнями змінної довжини передбачає надання кожному повідомленню заголовка, який містить як мінімум довжину наступного за ним тіла. Приймальний додаток читає повідомлення в два прийоми: спочатку заголовок фіксованої довжини, і з нього вилучається змінна довжина тіла повідомлення, а потім саме тіло. Лістинг функції (readvrec), який зреалізовує другий спосіб, розміщується у додатку. Ця функція є стандартизована і входить у бібліотеку letcp.
Першою фазою є стадія компіляції, коли файли з вихідними текстами програм, включаючи файли заголовків, опрацьовуються компілятором сс. Параметри компіляції можуть задаватися або за допомогою файла makefile (чи Makefile), або явною вказівкою необхідних опцій компілятора в командному рядку. У підсумку компілятор створює набір проміжних об’єктних файлів (server.o, client.o). Традиційно імена створених об'єктів мають суфікс “.o”. На наступній стадії ці файли за допомогою редактора сполучень зв’язків ld сполучуються один з одним і з різними бібліотеками, включаючи стандартну бібліотеку за замовчуванням і бібліотеки, зазначені користувачем як параметри (letcp). При цьому редактор сполучень зв’язків може виконуватися в двох режимах: статичному й динамічному, що задається відповідними опціями. У статичному, найбільш традиційному режимі, сполучуються всі об’єктні модулі та статичні бібліотеки (їхні імена мають суфікс “.a”, у даному разі вони містяться в./lib/*.a), виробляється дозвіл усіх зовнішніх надсилань модулів і створюється єдиний виконуваний файл, який утримує весь необхідний для виконання код. В другому випадку редактор сполучень зв’язків за можливістю підключає поділювані бібліотеки (імена цих бібліотек мають суфікс “*.so”). Внаслідок того створюється виконуваний файл, до якого в процесі запуску на виконання буде підключено всі поділювані об’єкти. В обох випадках за замовчуванням створюється виконуваний файл з ім’ям a.out.
