TCP

[Matroskin]

Где можно почитать про tcp ip в labview?

Вот нашел пример, немного его переработал

[Pavel Krivozubov]

Где можно почитать про tcp ip в labview?

Вот нашел пример, немного его переработал

Почитать про TCP/IP можно например тут:
http://www.automationlabs.ru/forum/show ... stcount=10
я в свое время по этой книжке начал изучать LV.

[Eugen Graf]

Где можно почитать про tcp ip в labview?

Вот нашел пример, немного его переработал

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

Если оставить в нижнем цикле задержку, то может случится так, что буфер переполнится, хотя и не обязательно.

А что именно интересует по теме TCP/IP ?

[willzon]

... А что именно интересует по теме TCP/IP ?

А интересует решение простейшей задачи: получаем результат на одной машине(число А), а на другой машине надо его увидеть, то есть мониторить число А с периодом , напр., 5сек.
(ворос для рубрики "Чайники", но тема больно подходящая). Заранее, спасибо.

[Pavel Krivozubov]

... А что именно интересует по теме TCP/IP ?

А интересует решение простейшей задачи: получаем результат на одной машине(число А), а на другой машине надо его увидеть, то есть мониторить число А с периодом , напр., 5сек.
(ворос для рубрики "Чайники", но тема больно подходящая). Заранее, спасибо.

Начни с примера Simple Data Server (Client).

[Eugen Graf]

Это точно. Я тоже с этого примера начинал.

А вообще есть одна популярная альтернатива для TCP/IP - Shared Variable, говорят с ней очень легко работать, хотя я ей никогда не пользовался. Я думаю для такой простой задачи как мониторинг она как раз подойдёт.

А вот здесь я делал пример коммуникации двух компов по TCP/IP в оба направления:
/viewtopic.php?f=14&t=328

[Matroskin]

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

и вот сразу же первые вопросы..)
1. зачем создан TCP listen, а не TCP Open Connection?
т.е правильно ли я понимаю, что слушатель создается для проверки принимающего соединения?
2. можно ли было сделать наоборот,чтобы слушатель был с принимающей стороны, т.е ждал пока на порт придут данные?

[Eugen Graf]

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

[Matroskin]

eg

ага, спасибо)

[Matroskin]

А как реализовать 2-хстороннюю связь?
Правильно ли будет установить соединения по 2-м портам, а потом постоянно считывать данные с соответсвующего порта?

[Pavel Krivozubov]

А как реализовать 2-хстороннюю связь?
Правильно ли будет установить соединения по 2-м портам, а потом постоянно считывать данные с соответсвующего порта?

Для обеспечения двусторонней связи достаточно добавить модули чтения TCP в сервер и клиент. Посмотри как это сделано в примере TCP Communicator Active (Passive).

[Matroskin]

спасибо :)
вроде заработало :)
клиент почти тоже самое, только вместо listen стоит open :)
буду немного модернизировать, хочу сдеалть чтото чато-подобное :)

[maxgod145]

Ага!А можно как то на базе стейт машины предложенной Anthony Lukindo,(http://expressionflow.com/?x=15&y=11&s= ... chitecture) серверную программу???!В неё должны записываться вся история для админа, и она должна опрашивать постоянно всех клиентов!Тоесть через неё должны общаться все клиенты!

[Eugen Graf]

Ну про конкретно эту стейт машину я ничего сказать не могу (она в твоём задании совершенно лишняя). А сервер это такое приложение, которое работает постоянно и независимо от клиента (ов). TCP/IP сервер должен ждать и уметь принимать все входящие соединения по TCP/IP. Его основные состояния (state) именно ожидание входящих соединений и сообщений от клиентов.

И так он состоит из одного основного цикла, который принимает соединения и записывает статические данные клиента (имя, номер, пароль и т.д.) в базу данных или же обычный табличный файл. Так же имеет сдвиговый регистр с динамичными данными (такие как reference number, флэг онлайн/оффлайн, пуфер с сообщениями и подобное). Этот сдвиговый регистр является хранилищем массива для классов клиентов о котором позже.

В общих словах сервер это ишак, который выполняет всю работу. А клиент это как бы хозяин, который посылает команды серверу и получает результат выполненых команд.

Если бы я делал такое задание на базе ООП, а я бы именно так и поступил, то прибор сервера состоял бы из двух классов:

класс база данных
и массив классов клиентов

Класс база данных имел бы все возможные Members и Methods, касающиеся работы с базой данных:
Members - название файла БД
Methods - открыть БД, закрыть БД, добавить запись, удалить запись, выдать запись

Класс клиент имел бы все Members и Methods, касающиеся клиента:
Members - номер соединения (TCP Refnum), флэг онлайн/оффлайн (то же самое что и logged in/not logged in)
Methods - login, logout, register, send message

В принципе вот и всё, что нужно для создания такого сервера.

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

ЗЫ если такие понятия как Members и Methods непонятны, то это соответственно Кластер и СубВи.

[maxgod145]