Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, AlexGin, Вы писали:

AG>>Все данные объединены в записи, эти записи имеют ПЕРЕМЕННУЮ длину.
AG>>Я предлагаю применять самопальный протокол, на базе TCP/IP. При этом в одном пакете объединять одну или несколько записей.
AG>>Конкретно, этот самопальный протокол я планирую в ближайшее время разработать.

Pzz>Посмотрите на zeromq: http://zeromq.org/
Спасибо, но у меня Visual Studio — то есть выбор: MFC или .NET.

AG>>Коллега по работе предлагет применить FTP и формировать файлы. В каждом таком файле — множество (тысячи) записей.

Pzz>А кто их стирать оттуда будет, эти файлы?
ПО прибора будет удалять файлы, после того, как они окажутся невостребованными (по типу кольцевого буфера).

AG>>Однако, нам не ясно, как будет работать FTP при внезапном обрыве связи.
AG>>ИМХО, в этом случае придется повторять весь огромный файл снова — что не есть хорошо...

Pzz>Это, как раз, не особая проблема. FTP позволяет докачивать файлы после обрыва. Но HTTP удобнее — хоть не надо с 2-мя TCP-соединениями возиться.
Уважаемый Pzz, насчёт двух соединений — можно как-то поподробнее? Мне пока видится только одно (HTTP или TCP соединение)...

AG>>На мой взгляд, работа через специализированный протокол удобнее и гибче.
AG>>Если имееет место обрыв связи, то легче его диагносцировать и затем возобновить докачку.

Pzz>С другой стороны, если заранее об этом не подумать, слециализированный протокол будет сложнее изменять, вслед за меняющимися требованиями.
Возможно.
Однако, тут есть и другой фактор — изменение специализарованного протокола — всегда в моих руках (да, иногда и сложнее — но НЕ НЕВОЗМОЖНО);
а вот со стандартными — шаг влево или вправо (от генеральной линии партии) карается расстрелом.

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, AlexGin, Вы писали:

AG>>Все данные объединены в записи, эти записи имеют ПЕРЕМЕННУЮ длину.
AG>>Я предлагаю применять самопальный протокол, на базе TCP/IP. При этом в одном пакете объединять одну или несколько записей.
AG>>Конкретно, этот самопальный протокол я планирую в ближайшее время разработать.

Pzz>Посмотрите на zeromq: http://zeromq.org/
Спасибо, поищу это всё под Visual Studio (именно она у нас применяется).
Еще такой вопрос — как поддержать это дело на стороне прибора?

AG>>Коллега по работе предлагет применить FTP и формировать файлы. В каждом таком файле — множество (тысячи) записей.

Pzz>А кто их стирать оттуда будет, эти файлы?
ПО прибора будет удалять файлы, после того, как они окажутся невостребованными (по типу кольцевого буфера).

AG>>Однако, нам не ясно, как будет работать FTP при внезапном обрыве связи.
AG>>ИМХО, в этом случае придется повторять весь огромный файл снова — что не есть хорошо...

Pzz>Это, как раз, не особая проблема. FTP позволяет докачивать файлы после обрыва. Но HTTP удобнее — хоть не надо с 2-мя TCP-соединениями возиться.
Уважаемый Pzz, насчёт двух соединений — можно как-то поподробнее? Мне пока видится только одно (HTTP или TCP соединение)...

AG>>На мой взгляд, работа через специализированный протокол удобнее и гибче.
AG>>Если имееет место обрыв связи, то легче его диагносцировать и затем возобновить докачку.

Pzz>С другой стороны, если заранее об этом не подумать, слециализированный протокол будет сложнее изменять, вслед за меняющимися требованиями.
Возможно.
Однако, тут есть и другой фактор — изменение специализарованного протокола — всегда в моих руках (да, иногда и сложнее — но НЕ НЕВОЗМОЖНО);
а вот со стандартными — шаг влево или вправо (от генеральной линии партии) карается расстрелом.