Способы передачи файлов по сети. Кроссплатформенно.

Вопросы программирования и использования среды Lazarus.

Модератор: Модераторы

Re: Способы передачи файлов по сети. Кроссплатформенно.

Сообщение stikriz » 12.06.2012 13:10:36

неправильно.
Аватара пользователя
stikriz
энтузиаст
 
Сообщения: 612
Зарегистрирован: 15.03.2006 09:37:47

Re: Способы передачи файлов по сети. Кроссплатформенно.

Сообщение alexey38 » 13.06.2012 06:13:07

Padre_Mortius писал(а): Прежде, чем так утверждать, нужно головой думать.
Я повторю тоже самое. Вы никогда не работали в большой организации.
Если речь идет о корпорациях, то там на FreePascal в принципе никто не даст написать средство передачи файлов по сети.
В большинстве случаев там пишут на том, что знают сотрудники (а в большинстве случаев это вообще оказывается VBA), если надо, то за примерами можно сходить на тот же hh.ru.
Шаг вправо или влево - расстрел, таковы правила крупных корпораций, которые не хотят разбираться как устроена некая частная технология.
Под каждый проект пишется документация и определяются ресурсы, которые необходимы данному проекту. Ресурсы эти определяются только по согласованию с системными администраторами и безопасниками. Решения же на основе сокетов в большинстве случаев будут опасней нежели стандартные http, ftp или smb


Про общее:
1. Судя по всему именно Вы не работали в большой организации, а если и работали, то она называлась базар (в смысле торговый рынок). Я, в отличие от Вас, и работал в корпорациях. И сейчас занимаюсь написанием прикладного софта для корпораций, моя нынешняя организация не крупная (всего 500 чел).
2. Ваша философия считает VBA оскорблением. Но факт в том, что VBA является стандартом для очень многих корпораций. И там пишут на VBA не потому, что лохи. А потому, что только так разрешено.
3. ИТ-администрация (в корпорациях это не админ, а дирекция по ИТ) и службы безопасности в крупных корпорациях в 99% случаях требуют применения стандартного для их корпорации софта. Этой ИТ-дирекции лень разбираться в 100 модификациях SQL-серверов и т.п. Например, они решили Oracle, и будет везде Oracle. Чтобы получить разрешение на Firebird нужно не знаю что сделать, наверное дать взятку в 1 млн.долл. (Oracle будет намного дешевле, чем такая взятка).

Теперь про частности. Что такое "крутые фишки"? Если простая задача по передачи файла в рамках локальной сети решена с использованием sql-сервера и web-сервера, то именно такая реализация будет называться с использованием "крутых фишек". По ней можно написать статью, защитить диссертацию, получить премию за навороты от непонимающего начальства. С позиции сопровождения имеем, что для реализации прикладной задачи будет использоваться миллионы строк кода. Насколько они безопасны - это вопрос. Например, поставили MySql или FireBird и вышла новая версия. Нужно ли ее обновлять? В корпорациях автообновление запрещено, т.к. требуется синхронизация с бизнес-процессами (их выполняют в нерабочее время). И бедному админу крупной корпорации придется писать отчет своему начальнику с указанием нужно ли или не нужно выполнять обновление на конкретный релиз.

Что такое низкоуровневые функции:
а) Это стандартные технологии, т.к. API, SDK - очень хорошо документированы. Есть статьи, форумы и т.п.
б) В самих низкоуровневых функциях нет дыр, т.к. при их наличии очень быстро выпускается обновление к ядру ОС. Например, дырка в сокете приведет к дыркам в веб, фтп и т.п., т.к. все работают через сокеты.
в) При использовании низкоуровневого API пишется только требуемый функционал. Иного функционала нет, поэтому и дыр нет.

Если при использовании низкоуровневых функций код программы будет 50-100-200 строк, то безусловно низкоуровневые функции предпочтительнее.
Если же Вам нужна реализация 1000 функций, и программа использующая низкоуровневые функции станет объемом тысячу строк и более, то конечно нужно переходить на стандарты более высокого уровня.

И главное. Хороший прикладной программист, использующий высокоуровневые стандарты должен владеть низкоуровневыми технологиями. Бизнес-логика абстрагируется от нижнего уровня. А программист должен понимать, как работают высокоуровневые технологии, иначе он не обеспечит не безопасность, ни надежность, ни эффективность. Полезно просто полазить в исходниках высокоуровневой библиотеки. Во-первых, начинаешь понимать как это работает. А, главное, делаешь вывод использовать или не использовать ее. Если код полное "г", то нужно держаться подальше от такой библиотеки. В ней будет куча дырок и багов. А если код лаконичен, читабелен, ясен, то можно ее использовать.

А то начинаются разговоры: веб или сокеты. А что такое веб? Какая библиотека используется? Кто уверен за качество именно этой библиотеки? Кто гарантирует точность документации именно на на нее? Вроде бы стандартный веб, а в любых браузерах ежемесячно находится сотни багов. А в ядре ОС багов находят на несколько порядков меньше. И в том же Линуксе какая диктатура в части изменения функций ядра или базовых библиотек.

Добавлено спустя 16 минут 35 секунд:
vitaly_l писал(а): По возможности надо в своих приложениях надо придерживаться общепринятых стандартов
Лично я - говорю тоже самое... Топик стартер создаёт кросплатформенную сеть (файловый сервер)... Соответственно нужно использовать кросплатформенные разработки высокого уровня..., (а не писать код на низкоуровневом машинном языке, когда есть Лазарус...) <=== метафора для аналогии :roll:


1. API от ОС - это и есть общепринятый стандарт. Никто не говорит об использовании недокументированных фишек.
2. При использовании API от ОС - не надо писать на машинном коде. Речь идет об разговоре с ОС на языке понятном ОС, а не через посредников (среди посредников очень легко попасться на сомнительных, как и в обычной жизни). ОС - это уже не самый низкий уровень, собственно ОС и были разработаны чтобы общение с железом довести до некого унифицированного и понятного всем уровня.
3. Для работы с сокетами можно и нужно использовать библиотеки обертки. В том, числе и кросс-платформенными.
4. Чтобы передать файл по сети через сокет нужно знать, предположим, 10 единиц информации (набор функций и иметь общее понимание об TCP, IP, OSI и т.п.). Чтобы реализовать передачу файлов через веб-сервер нужно знать 100 единиц информации. Установили веб-сервер по дефолту. А безопасно ли это дефолтное состояние? Открываешь конфигурационный файл того же Apche и там 1000 настроек. Нужно их менять или оставить по дефолту? Можно прикомпилировать некий веб-сервер к своему приложению, а у него ведь тоже не одна функция. Как это работает? Кто знает, нужно изучать и изучать. В отличие от этих наворотов, про сокет не нужно знать много. Это на несколько порядков проще и понятнее.

Добавлено спустя 55 минут 53 секунды:
И еще небольшое дополнение.
Чем отличается сокет-сервер от веб-сервера?
Веб-сервер в соответствии со стандартом обязан обрабатывать 1000 или даже больше вариантов запросов со стороны клиента. Вам для передачи файла нужна всего одна вариация запроса, а реализовать нужно все, иначе будет расхождение со стандартом, т.е. нестандартный сервер.

Сокет-сервер нужно написать на обработку только нужных Вам запросов. Ничего не мешает клиенский запрос на скачку файла реализовать через типовой http запрос (метод GET) на скачку файла. Можно проще, а можно и так.
Реализуя сокеты у Вас свобода действий. Можно применить свои запросы и подтверждения. А можно из некого высокоуровневого стандарта. По сути все вариации по формату кадров.
Вначале выбираете: текстовый или бинарный. Далее выбираете кодировку: utf8, utf16, в бинарном выбираете порядок следований байтов в 16, 32 и 64 значениях и т.п. Далее, собственно сам формат кадров.
Не обязательно изобретать велосипед. Можно воспользоваться стандартными кодировками.

Все отличие от веб-сервера в том, что не нужно реализовывать все методы стандартного http, а достаточно реализовать нужные Вам.
alexey38
долгожитель
 
Сообщения: 1627
Зарегистрирован: 27.04.2011 19:42:31

Re: Способы передачи файлов по сети. Кроссплатформенно.

Сообщение stikriz » 13.06.2012 08:26:29

alexey38 писал(а):Что такое "крутые фишки"? Если простая задача по передачи файла в рамках локальной сети решена с использованием sql-сервера и web-сервера, то именно такая реализация будет называться с использованием "крутых фишек".

Да. Это называется заткнуть дыру, потому, что написать этот функционал надо было еще вчера. Но, перевозить ящик пива с места на место с использованием космического корабля "Союз" - это говорит о квалифиеации руководителя отдела внедрений :-)
alexey38 писал(а): В самих низкоуровневых функциях нет дыр, т.к.

Открываем серверный сокет, а там простенький алгоритм, без проверок ipшника, без проверок самописного протокола, с долгой, длинной, нудной функцией авторизации по данным в БД, например, а потом получаем дос атаку. Использование, например, сокетов, а не кома ничего не говорит о безопасности продукта.
alexey38 писал(а):Полезно просто полазить в исходниках высокоуровневой библиотеки.

Ну, полазийте в исходниках DCOM или .NET. Даже открытые исходники почти ничего не дают. Потому, что реализация частностей затеняет смысл написаного. Например, тот же FireBird вряд-ли кто-то поймет просто там полазив :-) Два года - как минимум изучения кода.
Аватара пользователя
stikriz
энтузиаст
 
Сообщения: 612
Зарегистрирован: 15.03.2006 09:37:47

Re: Способы передачи файлов по сети. Кроссплатформенно.

Сообщение vitaly_l » 13.06.2012 14:24:35

alexey38 писал(а):нужно изучать и изучать. В отличие от этих наворотов, про сокет не нужно знать много. Это на несколько порядков проще и понятнее.

Сокеты - много удобнее. Согласен. И на них(сокетах), на самом деле, проще написать сервер на 10000 - вариантов запросов (не понимаю почему Вы говорите, что на сокетах сложнее готовить чем на http? точнее... смотря что готовить... Если функционал, то сокеты проще(ещё точнее без разницы)... а вот всё остальное... нужно знать много больше чем просто настройки апачи).

Вопрос в основном в безопасности, надёжности и возможно совместимости... (Безусловно профи вскроет/поломает и то и другое...) Сокеты априори проще. Почему тогда никто не использует?

Чтобы понять, можно поставить вопрос в процентном соотношении:
    Насколько процентов из ста использование сокетов опаснее http или ftp?
    Сколько нужно вложить в сокеты, чтобы получить защиту и совместимость наподобии http или ftp?
    (про остальное не говорю т.к. перекачиваются только файлы)
    Может тогда вообще отказаться от http и ftp?



.
Аватара пользователя
vitaly_l
долгожитель
 
Сообщения: 3333
Зарегистрирован: 31.01.2012 16:41:41

Re: Способы передачи файлов по сети. Кроссплатформенно.

Сообщение Mr.Smart » 13.06.2012 15:16:06

Если вам знакома ISO модель (хотя...).
Socket (Сокеты) - транспортный уровень
HTTP, FTP ... - прикладной уровень

т.е. Протокол HTTP, FTP и т.п. используют именно Сокеты для соединения и передачи данных...
Mr.Smart
долгожитель
 
Сообщения: 1796
Зарегистрирован: 29.03.2008 01:01:11
Откуда: из леса!

Re: Способы передачи файлов по сети. Кроссплатформенно.

Сообщение stikriz » 13.06.2012 15:36:33

Mr.Smart писал(а):т.е. Протокол HTTP, FTP и т.п. используют именно Сокеты для соединения и передачи данных...

Это, типа, а пацаны то и не знают? :-)
Проще надо думать. HTTP для страничек в интернет. FTP для закачивания и скачивания файлов. А где тут для обмена и обработки? Нету?
Аватара пользователя
stikriz
энтузиаст
 
Сообщения: 612
Зарегистрирован: 15.03.2006 09:37:47

Re: Способы передачи файлов по сети. Кроссплатформенно.

Сообщение vitaly_l » 13.06.2012 18:44:25

stikriz писал(а):А где тут для обмена и обработки? Нету?

Почему нету??? HTTP - протокол позволяет обмен и обработку... Текст html странички - возвращать необязательно...
Кстати, объём набивания самого кода, при HTTP обмене - занимает три строчки, а не 10 функций...



.
Аватара пользователя
vitaly_l
долгожитель
 
Сообщения: 3333
Зарегистрирован: 31.01.2012 16:41:41

Re: Способы передачи файлов по сети. Кроссплатформенно.

Сообщение stikriz » 13.06.2012 21:03:43

Это нестандартное его использование. Придуман он на основе OpenDoc для разметки текстовых документов с картинками. Гусь тоже и летает и плавает и ходит... И все это он делает плохо.
Аватара пользователя
stikriz
энтузиаст
 
Сообщения: 612
Зарегистрирован: 15.03.2006 09:37:47

Re: Способы передачи файлов по сети. Кроссплатформенно.

Сообщение vitaly_l » 13.06.2012 21:49:51

stikriz писал(а):Гусь тоже и летает и плавает и ходит... И все это он делает плохо.

Дык я и не спорю: орёл, по характеристикам - явно не гусь...
HTTP - для страничек в интернет...
FTP - для закачивания и скачивания файлов...
Сокеты - для обмена и обработки...
Шаг влево шаг вправо - расстрел.


PS: Можно подумать: орлы - хорошо плавают... :arrow: :cry:
.
Аватара пользователя
vitaly_l
долгожитель
 
Сообщения: 3333
Зарегистрирован: 31.01.2012 16:41:41

Re: Способы передачи файлов по сети. Кроссплатформенно.

Сообщение Padre_Mortius » 13.06.2012 22:46:36

2. Ваша философия считает VBA оскорблением. Но факт в том, что VBA является стандартом для очень многих корпораций. И там пишут на VBA не потому, что лохи. А потому, что только так разрешено.

Моя философия считает, что VBA, как и freepascal является частью зоопарка языков программирования. А большая часть доработок пишется на встроенных языков в тот или иной продукт (тут может быть и Clarion, и PL-SQL и многое другое). Извините, но в больших корпорациях наколенные поделки последнее время становятся моветоном, ибо все стремятся к централизации.

ИТ-администрация (в корпорациях это не админ, а дирекция по ИТ) и службы безопасности в крупных корпорациях в 99% случаях требуют применения стандартного для их корпорации софта. Этой ИТ-дирекции лень разбираться в 100 модификациях SQL-серверов и т.п.

И чем это отличается от моих слов? Я немного упростил структуру, но смысл вроде тот же.

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

"Крутые фишки" и "быдло"-ИТ-менеджмент это немного разные вещи.. Можно и микроскопом гвозди забивать, но он не для этого предназначен. Инструменты выбираются под задачу, а не на оборот. И если ИТ-менеджер не может понять проблемы, то это проблемы не программиста, а менеджера.

4. Чтобы передать файл по сети через сокет нужно знать, предположим, 10 единиц информации (набор функций и иметь общее понимание об TCP, IP, OSI и т.п.). Чтобы реализовать передачу файлов через веб-сервер нужно знать 100 единиц информации. Установили веб-сервер по дефолту. А безопасно ли это дефолтное состояние? Открываешь конфигурационный файл того же Apche и там 1000 настроек. Нужно их менять или оставить по дефолту? Можно прикомпилировать некий веб-сервер к своему приложению, а у него ведь тоже не одна функция. Как это работает? Кто знает, нужно изучать и изучать. В отличие от этих наворотов, про сокет не нужно знать много. Это на несколько порядков проще и понятнее.

А вот тут играет роль распределение задач. За кривую настройку веб-сервера отвечает системный администратор, а за кривую реализацию на сокетах - программист. Разницу видите?

Сокет-сервер нужно написать на обработку только нужных Вам запросов.

И получить ни с чем не совместимый уникальный сервис.

Этой ИТ-дирекции лень разбираться в 100 модификациях SQL-серверов и т.п.

Не чувствуете противоречия? Зачем тем же админам еще один квадратноколесный велосипед, если есть вполне стандартный http-сервер, которых в конторе стоит с 10-ток штук.

в) При использовании низкоуровневого API пишется только требуемый функционал. Иного функционала нет, поэтому и дыр нет.

Мне бы вашу уверенность. Для написания сервера на тех же сокетах, нужно будет не только разрулить вопросы безопасности, целостности протокола передачи данных, но еще и разрулить нормальную очередь сообщений, с которой у большинства программистов почему-то возникают проблемы. Как пример могу привести очень распространенное ПО в банковской сфере (система переводов Юнистрим). Реализация на Borland Socket Error, но очередь сообщений настолько криво реализована, что при определенном количестве подключений получается своего рода ddos-атака. Поэтому более реально использовать уже готовый продукт, а по поводу админов тут ответ очень прост. Если будет согласован %product_name% (подставьте нужное), то админы никуда не денутся и будут и обновлять его и бекапить и проводить все остальные мероприятия, необходимые для стабильной работы системы.
Padre_Mortius
энтузиаст
 
Сообщения: 1265
Зарегистрирован: 29.05.2007 17:38:07
Откуда: Спб

Re: Способы передачи файлов по сети. Кроссплатформенно.

Сообщение stikriz » 13.06.2012 22:59:09

vitaly_l писал(а):Сокеты - для обмена и обработки...

Ваш протокол на сокетах для решения Ваших задач.
Чем выше технология, тем уже она специализирована, если хорошо работает.
Если же это вообще для всего, как .NEt или CORBA, то это гусь :-)
Оптимизирывать по всем свойствам невозможно - это закон природы. Иначе не было бы видов - достаточно одного животного.
Аватара пользователя
stikriz
энтузиаст
 
Сообщения: 612
Зарегистрирован: 15.03.2006 09:37:47

Re: Способы передачи файлов по сети. Кроссплатформенно.

Сообщение vitaly_l » 13.06.2012 23:13:03

stikriz писал(а):Оптимизирывать по всем свойствам невозможно - это закон природы. Иначе не было бы видов - достаточно одного животного.

Ага... теперь мне понятна эволюция видов... :roll: stikriz рулит: теория Дарвина - отдыхает... :P
Аватара пользователя
vitaly_l
долгожитель
 
Сообщения: 3333
Зарегистрирован: 31.01.2012 16:41:41

Re: Способы передачи файлов по сети. Кроссплатформенно.

Сообщение stikriz » 13.06.2012 23:15:03

Padre_Mortius писал(а):Мне бы вашу уверенность. Для написания сервера на тех же сокетах, нужно будет не только разрулить вопросы безопасности, целостности протокола передачи данных, но еще и разрулить нормальную очередь сообщений, с которой у большинства программистов почему-то возникают проблемы.

Это, как говорил тов. Ленин их детские трудности :-) У большинства программистов нет проблем с реализацией протокола на сокетах и маршалинга на тех же TParams.
Код: Выделить всё
  TUnParametr = class(TObject)
    private
      FName: string;
      FParamType: TUnParamType;
      FTag: Integer;
      procedure CreateConvertionError(ADataType: TUnDataTypes);
    protected
      function GetAsBlob: TStream; virtual;
      procedure SetAsBlob(AValue: TStream); virtual;
      function GetAsInt64: Int64; virtual;
      function GetAsBoolean: boolean; virtual;
      function GetAsByte: Byte; virtual;
      function GetAsCardinal: Cardinal; virtual;
      function GetAsCurrency: Currency; virtual;
      function GetAsDateTime: TDateTime; virtual;
      function GetAsDouble: Double; virtual;
      function GetAsGUID: TGUID; virtual;
      function GetAsLongInt: LongInt; virtual;
      function GetAsShortInt: ShortInt; virtual;
      function GetAsSingle: Single; virtual;
      function GetAsSmallint: Smallint; virtual;
      function GetAsString: string; virtual;
      function GetAsWord: Word; virtual;
      function GetDataType: TUnDataTypes; virtual; abstract;
      function GetValue: Variant; virtual; abstract;
      function GetWideString: WideString; virtual;
      procedure SetAsBoolean(AValue: boolean); virtual;
      procedure SetAsByte(AValue: Byte); virtual; abstract;
      procedure SetAsCardinal(AValue: Cardinal); virtual;
      procedure SetAsCurrency(AValue: Currency); virtual;
      procedure SetAsDateTime(AValue: TDateTime); virtual;
      procedure SetAsDouble(AValue: Double); virtual;
      procedure SetAsGUID(AValue: TGUID); virtual;
      procedure SetAsInt64(AValue: Int64); virtual;
      procedure SetAsLongInt(AValue: LongInt); virtual;
      procedure SetAsShortInt(AValue: ShortInt); virtual;
      procedure SetAsSingle(AValue: Single); virtual;
      procedure SetAsSmallint(AValue: Smallint); virtual;
      procedure SetAsString(AValue: string); virtual;
      procedure SetAsWord(AValue: Word); virtual;
      procedure SetValue(AValue: Variant); virtual; abstract;
      procedure SetWideString(AValue: WideString); virtual;
    public
      procedure LoadFromStream(AStr: TStream); virtual;
      procedure SaveToStream(AStr: TStream); virtual;

      property DataType: TUnDataTypes read GetDataType;
      property ParamType: TUnParamType read FParamType write FParamType;

      property Value: Variant read GetValue write SetValue;
      // Int
      property AsShortInt: ShortInt read GetAsShortInt write SetAsShortInt;
      property AsSmallint: Smallint read GetAsSmallint write SetAsSmallint;
      property AsByte: Byte read GetAsByte write SetAsByte;
      property AsWord: Word read GetAsWord write SetAsWord;
      property AsLongInt: LongInt read GetAsLongInt write SetAsLongInt;
      property AsCardinal: Cardinal read GetAsCardinal write SetAsCardinal;
      property AsInt64: Int64 read GetAsInt64 write SetAsInt64;
      // Float
      property AsSingle: Single read GetAsSingle write SetAsSingle;
      property AsDouble: Double read GetAsDouble write SetAsDouble;
      property AsCurrency: Currency read GetAsCurrency write SetAsCurrency;
      // String
      property AsString: string read GetAsString write SetAsString;
      property AsWideString: WideString read GetWideString write SetWideString;
      property AsBoolean: boolean read GetAsBoolean write SetAsBoolean;
      property AsDateTime: TDateTime read GetAsDateTime write SetAsDateTime;
      property AsGUID: TGUID read GetAsGUID write SetAsGUID;
      // Blob
      property AsBlob: TStream read GetAsBlob write SetAsBlob;

      property Name: string read FName write FName;
      property Tag: Integer read FTag write FTag;
  end;

  { TUnCommand }

  TUnCommand = class(TObject)
    private
      FErrorCode: Integer;
      FErrorString: string;
      FListVariables: TList;
      FName: string;
      FTag: Integer;
      function GetCount: Integer;
      function GetParam(AIndex: Integer): TUnParametr;
    protected
    public
      constructor Create;
      destructor Destroy; override;
      procedure Clear;
      procedure LoadFromStream(AStr: TStream);
      procedure SaveToStream(AStr: TStream);
      function ParamByName(const AName: string): TUnParametr;
      function FindParam(const AName: string; var AParam: TUnParametr): boolean;
      procedure Remove(AParam: TUnParametr);
      procedure Delete(AIndex: Integer; ADeleteParam: boolean = true);
      function GetNew(ADataType: TUnDataTypes): TUnParametr; overload;
      function GetNew(AValue: boolean): TUnParametr; overload;
      function GetNew(AValue: Byte): TUnParametr; overload;
      function GetNew(AValue: Cardinal): TUnParametr; overload;
      function GetNew(AValue: Currency): TUnParametr; overload;
      function GetNew(AValue: TDateTime): TUnParametr; overload;
      function GetNew(AValue: Double): TUnParametr; overload;
      function GetNew(AValue: TGUID): TUnParametr; overload;
      function GetNew(AValue: Int64): TUnParametr; overload;
      function GetNew(AValue: LongInt): TUnParametr; overload;
      function GetNew(AValue: ShortInt): TUnParametr; overload;
      function GetNew(AValue: Single): TUnParametr; overload;
      function GetNew(AValue: Smallint): TUnParametr; overload;
      function GetNew(AValue: string): TUnParametr; overload;
      function GetNew(AValue: Word): TUnParametr; overload;
      function GetNew(AValue: WideString): TUnParametr; overload;
      property Param[AIndex: Integer]: TUnParametr read GetParam; default;
      property Count: Integer read GetCount;
      property Name: string read FName write FName;
      property Tag: Integer read FTag write FTag;
      property ErrorString: string read FErrorString write FErrorString;
      property ErrorCode: Integer read FErrorCode write FErrorCode;
  end;

  { TUnPacket }

  TUnPacket = class(TObject)
    private
      FListCommands: TList;
      function GetCount: Integer;
      function GetItems(AIndex: Integer): TUnCommand;
    protected
    public
      constructor Create;
      destructor Destroy; override;
      procedure Clear;
      function CommandByName(const AName: string): TUnCommand;
      function FindCommand(const AName: string; var ACommand: TUnCommand): boolean;
      procedure LoadFromStream(AStr: TStream);
      procedure SaveToStream(AStr: TStream);
      function Add: TUnCommand;
      procedure Remove(ACommand: TUnCommand);
      procedure Delete(AIndex: Integer; ADeleteParam: boolean = true);
      property Commands[AIndex: Integer]: TUnCommand read GetItems; default;
      property Count: Integer read GetCount;
  end;

{ TUnParamBoolean }

  TUnParamBoolean = class(TUnParametr)
    private
      FValue: boolean;
    protected
      function GetAsInt64: Int64; override;
      function GetAsBoolean: boolean; override;
      function GetAsLongInt: LongInt; override;
      function GetAsShortInt: ShortInt; override;
       function GetAsSmallint: Smallint; override;
      procedure SetAsBoolean(AValue: boolean); override;

      procedure SetValue(AValue: Variant); override;
      function GetValue: Variant; override;
      function GetDataType: TUnDataTypes; override;
    public
      procedure LoadFromStream(AStr: TStream); override;
      procedure SaveToStream(AStr: TStream); override;
  end;           


Код: Выделить всё
function TDmDatabase.Run(APacket: TUnPacket): boolean;
var I: Integer;
    TmpCommand: TUnCommand;
begin
Result:=true;
try
  for I:=0 to APacket.Count-1 do
   begin
    TmpCommand:=APacket[I];
    Result:=Result and RunCommand(TmpCommand);
   end;
except
   Result:=false;
end;
end;

function TDmDatabase.RunCommand(ACommand: TUnCommand): boolean;
var Func: TServerMethod;
    I: Integer;
    Par: TUnParametr;
begin
try
  Result:=false;

  if FListMethods.Find(ACommand.Name, Func) then
   Result:=Func(ACommand)
  else
    Result:=false;

  I:=0;
  while I < ACommand.Count do
   begin
    Par:=ACommand.Param[I];
    if Par.ParamType in [unpt_Const, unpt_Input] then
     ACommand.Delete(I)
    else
      I:=I+1;
   end;

except on E: Exception do
  begin
    if E.ClassType = EUnDatabaseError then
     begin
      ACommand.ErrorCode:=EUnDatabaseError(E).ErrorCode;
      ACommand.ErrorString:=E.Message;
     end
    else
     begin
      ACommand.ErrorCode:=-1;
      ACommand.ErrorString:=E.Message;
     end;
  end;
end;
end;


Код: Выделить всё
procedure TDmDatabase.AddMethods(AListMethods: TUnListMethods);
begin
AListMethods.Add('RegistryUser', @RegistryUser);
AListMethods.Add('UnRegistryUser', @UnRegistryUser);
AListMethods.Add('GetFile', @GetFile);
AListMethods.Add('SendMessage', @SendMessage);
AListMethods.Add('GetListClient', @GetListClient);
AListMethods.Add('GetVersion', @GetVersion);
AListMethods.Add('GetListDatabases', @GetListDatabases);
AListMethods.Add('GetListUsers', @GetListUsers);



Не надо думать, что это все какое-то волшебство. Один раз написать болванку сервера, и юзай всю жизнь :-)

Padre_Mortius писал(а):И получить ни с чем не совместимый уникальный сервис.

Конечно, если Ваша задача еще ни кем не решена и уникальна. Есть такая программа, которая делает именно то, что нужно именно Вам? Если есть - проще купить. А если нет?

Добавлено спустя 54 секунды:
vitaly_l писал(а):Ага... теперь мне понятна эволюция видов... :roll: stikriz рулит: теория Дарвина - отдыхает... :P

Так это и есть эволюция.
Аватара пользователя
stikriz
энтузиаст
 
Сообщения: 612
Зарегистрирован: 15.03.2006 09:37:47

Re: Способы передачи файлов по сети. Кроссплатформенно.

Сообщение vitaly_l » 13.06.2012 23:32:49

stikriz писал(а):Так это и есть эволюция.

Далеко не факт, что это эволюция.
stikriz писал(а):Не надо думать, что это все какое-то волшебство. Один раз написать болванку сервера, и юзай всю жизнь

Всё относительно. (Эйнштейн)
В смысле synapse и Лазарус - тоже один раз готовили... а пользуют все... и получается рост и эволюция...
А в Вашем случае - роста нет, значит нет и эволюции.

Зачем орлу плавать, если есть зайцы?

.
Последний раз редактировалось vitaly_l 13.06.2012 23:35:19, всего редактировалось 1 раз.
Аватара пользователя
vitaly_l
долгожитель
 
Сообщения: 3333
Зарегистрирован: 31.01.2012 16:41:41

Re: Способы передачи файлов по сети. Кроссплатформенно.

Сообщение stikriz » 13.06.2012 23:35:17

vitaly_l писал(а): в вашем случае - роста нет, значит нет и эволюции.

Откуда Вы знаете о моем росте ? :-)
vitaly_l писал(а):Далеко не факт, что это эволюция.

Далеко не факт, что Вы в этом хоть что-то смыслите.
Аватара пользователя
stikriz
энтузиаст
 
Сообщения: 612
Зарегистрирован: 15.03.2006 09:37:47

Пред.След.

Вернуться в Lazarus

Кто сейчас на конференции

Сейчас этот форум просматривают: Yandex [Bot] и гости: 230

Рейтинг@Mail.ru