Передача данных между 2 GPRS модемами, Уважаемые, помогите. Нужна прога на С++, которая реализует передачу да Опции

[Yuriy_Rus]

Уважаемые, помогите. Нужна прога на С++, которая реализует передачу данных (восновном текстовых) между 2 GPRS модемами от одного компа к другому. Интерфейс модемов с компами -RS-232.
Может кто-то сталкивался с такой проблемой? Есть исходники?
Заранее, Спасибо.

[Yuriy_Rus]

Тип GPRS модема - WAVECOM FASTRACK

[beer_warrior]

Модем он и в Африке модем. Любой терминал поможет.

[BVU]

Модем он и в Африке модем. Любой терминал поможет.

Согласен на все сто! А то получается такое обстоятельство: "Покажите какие кнопки нажимать, а то ноты учить не охота..."

[san822]

Ну, во-первых понятно желание перед самостоятельным решением задачи
посмотреть на творения колегг. Я бы, наверное, тоже сделал такую попытку.
Во-вторых, человек спрашивает о возможности передачи.
Если я не ошибаюсь реализовать это можно не только через GPRS,
но и через CSD. Передавать планируется тексты,
т. е. обьём передачи не велик, поэтому и CSD может подойти.
Про выгодность - это зависит от тарифов оператора в зоне,
где будут работать модемы. У некоторых, например, звонки внутри сети очень дешевые или есть дешевые внутрисетевые безлимитки,
т. е. можно подумать о CSD - там ведь вроде оплата идет за время,
а не за обьем данных.

[BVU]

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

Несколько не так... Вопрос был задан именно:

... Нужна прога на С++, которая реализует передачу данных (восновном текстовых) между 2 GPRS модемами от одного компа к другому...

Обычно интересующийся человек спрашивает, как это сделать. И мы ему помогаем. А здесь сразу же дайте прогу... Открытых проектов по данной тематике очень мало, т.к. многие реализации в основном комерческие поскольку рынок изобилует спросом на эти услуги, и ничего странного, что здесь существует нормальная конкуренция.
Тем более, что у нас есть форум посвещенный данным проблемам, а здесь "Общение - Free talks" - ни к чему не обязывает...
Так что ничего личного, а просто выравнивание курса в 'нужное русло'...

[Yuriy_Rus]

to BVU - к словам цепляться не стоит. Попросил помочь. А тут уже и "кнопки нажимать не охота".

А по делу, кто небудь может подсказать пути решения моей проблемы.

[Chupakabra]

Уважаемые, помогите. Нужна прога на С++, которая реализует передачу данных (восновном текстовых) между 2 GPRS модемами от одного компа к другому. Интерфейс модемов с компами -RS-232.
Может кто-то сталкивался с такой проблемой? Есть исходники?
Заранее, Спасибо.

Если не ошибаюсь то обычный GPRS модем общается с PC чем-то вроде PPP или SLIP протоколом т.е. tcp/ip over PPP over RS-232. Кроме того в модеме может быть реализован в разной степени стек TCP/IP, и работа с портом (RS-232) ведется на уровне "последовательный порт" <-каким-то образом-> tcp/ip порт.

[Rst7]

Через GPRS нельзя организовать соединение точка-точка, так что только CSD

[Chupakabra]

Через GPRS нельзя организовать соединение точка-точка, так что только CSD

На транспортном и канальном уровнях модели OSI нельзя, на уровене приложений можно
Т.е. точка-точка может быть организована на уровне IP адрес:порт <-> IP адрес:порт.

[Rst7]

Через GPRS нельзя организовать соединение точка-точка, так что только CSD

На транспортном и канальном уровнях модели OSI нельзя, на уровене приложений можно
Т.е. точка-точка может быть организована на уровне IP адрес:порт <-> IP адрес:порт.

Как вы себе видите узнавание IP-адреса другого модема? Через какой-либо специально организованный сервер в инете? Выделение IP ведь динамическое...

[Yuriy_Rus]

Будет использоваться сервер.
Задача прог для каждого модема организовыать запросы на базовую станцию оператора моб. связи. Затем сообщать адресс модема на сервер(вторая прога в это время будет делать то же самое для другого модема). Затем организовывать запрос на сервер за IP другого модема (то же самое происходит на другом компе). Когда проги будут знать IP противоположных модемов "начнёться веселье".
Какими средствами С++ реализовать всё вышеизложенное?

[Chupakabra]

Через GPRS нельзя организовать соединение точка-точка, так что только CSD

На транспортном и канальном уровнях модели OSI нельзя, на уровене приложений можно
Т.е. точка-точка может быть организована на уровне IP адрес:порт <-> IP адрес:порт.

Как вы себе видите узнавание IP-адреса другого модема? Через какой-либо специально организованный сервер в инете? Выделение IP ведь динамическое...

Ну это уже расширение условий задачи. А вообще, да, нахаляву например www.dyndns.com/ или www.changeip.com, или платные сервисы - понадежней. Можно даже свой DNS на выделенном сервере организовать.

[Yuriy_Rus]

to Chupakabra
Правильно мыслишь.
Однако разговор идёт, а дело стоит.

(Пока. До завтра.)

[GetSmart]

После получения обоими модемами динамических IP-адресов нужно обменяться ими. Я бы предложил быстренько на пару секунд законнектиться через обычное модемное соединение, пускай даже по аналоговому каналу 9600 передать эти "циферки", а потом уже общаться через IP-адреса. Нужно только знать номера обоих телефонов. Благо GPRS позволяет одновременно "разговаривать" по телефону.

[Yuriy_Rus]

После получения обоими модемами динамических IP-адресов нужно обменяться ими. Я бы предложил быстренько на пару секунд законнектиться через обычное модемное соединение, пускай даже по аналоговому каналу 9600 передать эти "циферки", а потом уже общаться через IP-адреса. Нужно только знать номера обоих телефонов. Благо GPRS позволяет одновременно "разговаривать" по телефону.

Нет, тут весь смысл в том что есть два компа, два GPRS модема и передачу данных нужно организовывать без всяких (кроме сервера, кот. принимает и выдаёт IP) вспомогательных средств. Обычное модемное соединение использоваться не будет.

[Rst7]

После получения обоими модемами динамических IP-адресов нужно обменяться ими. Я бы предложил быстренько на пару секунд законнектиться через обычное модемное соединение, пускай даже по аналоговому каналу 9600 передать эти "циферки", а потом уже общаться через IP-адреса. Нужно только знать номера обоих телефонов. Благо GPRS позволяет одновременно "разговаривать" по телефону.

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

[GetSmart]

Нет, тут весь смысл в том что есть два компа, два GPRS модема и передачу данных нужно организовывать без всяких (кроме сервера, кот. принимает и выдаёт IP) вспомогательных средств. Обычное модемное соединение использоваться не будет.

Я имел ввиду модемное соединение через этот же GPRS-модем, только по аналоговому каналу. Я точно не знаю, но может быть именно оно называется CSD. Короче, кроме двух GPRS модемов ничего дополнительно не надо. И этот вариант гораздо лучше передачи двух СМС-ок. Да и быстрее.

[Rst7]

Нет, тут весь смысл в том что есть два компа, два GPRS модема и передачу данных нужно организовывать без всяких (кроме сервера, кот. принимает и выдаёт IP) вспомогательных средств. Обычное модемное соединение использоваться не будет.

Я имел ввиду модемное соединение через этот же GPRS-модем, только по аналоговому каналу. Я точно не знаю, но может быть именно оно называется CSD. Короче, кроме двух GPRS модемов ничего дополнительно не надо. И этот вариант гораздо лучше передачи двух СМС-ок. Да и быстрее.

Одной SMS, одной! От сервера клиенту. Этого хватит.

[GetSmart]

Пусть одной, но всё равно просто позвонить и скинуть десяток байт будет быстрее, чем ждать прихода этой СМС.

[Yuriy_Rus]

Нет, тут весь смысл в том что есть два компа, два GPRS модема и передачу данных нужно организовывать без всяких (кроме сервера, кот. принимает и выдаёт IP) вспомогательных средств. Обычное модемное соединение использоваться не будет.

Я имел ввиду модемное соединение через этот же GPRS-модем, только по аналоговому каналу. Я точно не знаю, но может быть именно оно называется CSD. Короче, кроме двух GPRS модемов ничего дополнительно не надо. И этот вариант гораздо лучше передачи двух СМС-ок. Да и быстрее.

Одной SMS, одной! От сервера клиенту. Этого хватит.

Сначала модем посылает свой динамический IP серверу. Затем принимает IP другого. Всё то же самое делает и другой модем. Как всё это делается одной SMS!? Или я чего-то неправильно понял? Я в GPRS модемах плоховато шарю.

[GetSmart]

Передаётся одной СМС один IP. Модем, получивший его посылает туда IP-пакет. Таким образом другой модем (сервер) получает IP-адрес клиента.

Но вариант с СМС неидеален. Как я уже говорил.

[Yuriy_Rus]

Передаётся одной СМС один IP. Модем, получивший его посылает туда IP-пакет. Таким образом другой модем (сервер) получает IP-адрес клиента.

Но вариант с СМС неидеален. Как я уже говорил.

Что-то то ли я не понимаю, то ли ты...
Что ты подразумеваешь под "ТУДА"?
Как один модем может стать сервером, а другой клиентом?
Сервер он на то и нужен, что IP у него постоянный. А у GPRS модема IP выдаются каждый раз новый при подключении. Т.е. модемы не могут общаться между собой сразу, т. к. каждый раз они не будут знать свои адреса. Задача сервера - обменять модемы адресами.

[Rst7]

Передаётся одной СМС один IP. Модем, получивший его посылает туда IP-пакет. Таким образом другой модем (сервер) получает IP-адрес клиента.

Но вариант с СМС неидеален. Как я уже говорил.

Что-то то ли я не понимаю, то ли ты...
Что ты подразумеваешь под "ТУДА"?
Как один модем может стать сервером, а другой клиентом?
Сервер он на то и нужен, что IP у него постоянный. А у GPRS модема IP выдаются каждый раз новый при подключении. Т.е. модемы не могут общаться между собой сразу, т. к. каждый раз они не будут знать свои адреса. Задача сервера - обменять модемы адресами.

Протокол TCP/IP подразумевает, что на одной стороне создается серверный сокет (ожидающий соединение), а на другой стороне клиентский (который является инициатором коннекта). После того, как поднялся PPP и вы в своей софтине создаете серверный сокет, становится известен его IP, который достаточно послать клиенту, чтобы тот выполнил соединение с этим IP. Но мы забыли одну вещь - не факт, что серверный сокет, открытый на GPRS будет работать. Я имею в виду проблемы класса active/passive режим для FTP например. Т.е. IP-адрес может быть присвоен модему из диапазона внутренних адресов, а далее транслироваться через NAT.

[Yuriy_Rus]

Передаётся одной СМС один IP. Модем, получивший его посылает туда IP-пакет. Таким образом другой модем (сервер) получает IP-адрес клиента.

Но вариант с СМС неидеален. Как я уже говорил.

Что-то то ли я не понимаю, то ли ты...
Что ты подразумеваешь под "ТУДА"?
Как один модем может стать сервером, а другой клиентом?
Сервер он на то и нужен, что IP у него постоянный. А у GPRS модема IP выдаются каждый раз новый при подключении. Т.е. модемы не могут общаться между собой сразу, т. к. каждый раз они не будут знать свои адреса. Задача сервера - обменять модемы адресами.

Протокол TCP/IP подразумевает, что на одной стороне создается серверный сокет (ожидающий соединение), а на другой стороне клиентский (который является инициатором коннекта). После того, как поднялся PPP и вы в своей софтине создаете серверный сокет, становится известен его IP, который достаточно послать клиенту, чтобы тот выполнил соединение с этим IP. Но мы забыли одну вещь - не факт, что серверный сокет, открытый на GPRS будет работать. Я имею в виду проблемы класса active/passive режим для FTP например. Т.е. IP-адрес может быть присвоен модему из диапазона внутренних адресов, а далее транслироваться через NAT.

Как можно послать от "модема-сервера" его IP клиенту, если IP клиента неизвестен.
И какими средствами C++ я могу узнать IP модема в момент, когда он приходит модему с Базовой станции?
Или я опять чего-то не догоняю? Просветите "доступным" языком, пожалуйста.

[GetSmart]

Я сам не знаю всех этих протоколов. Чисто на интуиции думаю.
Подразумевается, что один из телефонов известен другому. Например все клиенты должны знать телефонный номер сервера. В вашей задаче можно считать, что один из телефонов - сервер, а другой (или даже другие) - клиент. Проблема только в том, что сервер должен отсылать СМС, а он-то и не знает номер клиента.

Ситуация:
Один телефон регистрируется и получает IP. После он отправляет СМС с этим IP на сервер, телефонный номер которого он знает. Сервер после этого тоже регистрируется и уже через GPRS протокол (не знаю PPP или что-то ещё) отсылает на полученный им IP пакет данных. В этом пакете будет содержаться его собственный IP (сервера). Ну и далее они гоняют данные друг другу.

Если всё ПО писать под себя, то я бы вообще не стал вводить такое жёсткое разделение на клиент/сервер между двумя телефонами. Который первый инициировал соединение - тот и является клиентом. А изначально оба телефона могут быть равноценными.

[Chupakabra]

Я сам не знаю всех этих протоколов. Чисто на интуиции думаю.
Подразумевается, что один из телефонов известен другому. Например все клиенты должны знать телефонный номер сервера. В вашей задаче можно считать, что один из телефонов - сервер, а другой (или даже другие) - клиент. Проблема только в том, что сервер должен отсылать СМС, а он-то и не знает номер клиента.

Ситуация:
Один телефон регистрируется и получает IP. После он отправляет СМС с этим IP на сервер, телефонный номер которого он знает. Сервер после этого тоже регистрируется и уже через GPRS протокол (не знаю PPP или что-то ещё) отсылает на полученный им IP пакет данных. В этом пакете будет содержаться его собственный IP (сервера). Ну и далее они гоняют данные друг другу.

Если всё ПО писать под себя, то я бы вообще не стал вводить такое жёсткое разделение на клиент/сервер между двумя телефонами. Который первый инициировал соединение - тот и является клиентом. А изначально оба телефона могут быть равноценными.

Да что тут мудрить, про dyndns уже писал. Самый верхний уровень TCP/IP, без скатываения вниз. У каждого учасника обмена будет свое имя, скажем terminal1.dyndns.org - это константа, не меняется, и известно каждому участнику соединения (terminal2.dyndns.org, terminal3.... и т.п.). Используя службу DNS (ну и DynDNS соответственно, черех обращение к зоне DynDNS) эти имена переворачиватся в динамические IP адреса (выданные на данные момент провайдером). Все друг друга опознали и разговаривают между собой по тохнологии клиент-сервер (over TCP или UDP).

[Yuriy_Rus]

Я сам не знаю всех этих протоколов. Чисто на интуиции думаю.
Подразумевается, что один из телефонов известен другому. Например все клиенты должны знать телефонный номер сервера. В вашей задаче можно считать, что один из телефонов - сервер, а другой (или даже другие) - клиент. Проблема только в том, что сервер должен отсылать СМС, а он-то и не знает номер клиента.

Ситуация:
Один телефон регистрируется и получает IP. После он отправляет СМС с этим IP на сервер, телефонный номер которого он знает. Сервер после этого тоже регистрируется и уже через GPRS протокол (не знаю PPP или что-то ещё) отсылает на полученный им IP пакет данных. В этом пакете будет содержаться его собственный IP (сервера). Ну и далее они гоняют данные друг другу.

Если всё ПО писать под себя, то я бы вообще не стал вводить такое жёсткое разделение на клиент/сервер между двумя телефонами. Который первый инициировал соединение - тот и является клиентом. А изначально оба телефона могут быть равноценными.

Как программно на С++ реализовать "выемку" GPRS модемом своего IP, как только он его получил?
И как программно на С++ реализовать "отсыл" SMS на номер сервера?
Или это всё уникальные функции, зависящие от типа(марки изготовителя) модема?

Я сам не знаю всех этих протоколов. Чисто на интуиции думаю.
Подразумевается, что один из телефонов известен другому. Например все клиенты должны знать телефонный номер сервера. В вашей задаче можно считать, что один из телефонов - сервер, а другой (или даже другие) - клиент. Проблема только в том, что сервер должен отсылать СМС, а он-то и не знает номер клиента.

Ситуация:
Один телефон регистрируется и получает IP. После он отправляет СМС с этим IP на сервер, телефонный номер которого он знает. Сервер после этого тоже регистрируется и уже через GPRS протокол (не знаю PPP или что-то ещё) отсылает на полученный им IP пакет данных. В этом пакете будет содержаться его собственный IP (сервера). Ну и далее они гоняют данные друг другу.

Если всё ПО писать под себя, то я бы вообще не стал вводить такое жёсткое разделение на клиент/сервер между двумя телефонами. Который первый инициировал соединение - тот и является клиентом. А изначально оба телефона могут быть равноценными.

Да что тут мудрить, про dyndns уже писал. Самый верхний уровень TCP/IP, без скатываения вниз. У каждого учасника обмена будет свое имя, скажем terminal1.dyndns.org - это константа, не меняется, и известно каждому участнику соединения (terminal2.dyndns.org, terminal3.... и т.п.). Используя службу DNS (ну и DynDNS соответственно, черех обращение к зоне DynDNS) эти имена переворачиватся в динамические IP адреса (выданные на данные момент провайдером). Все друг друга опознали и разговаривают между собой по тохнологии клиент-сервер (over TCP или UDP).

Расскажи подробнее про DNS(DynDNS) как там, и что? Как реализовано "переворачивание" имён в динамические IP?

[Yuriy_Rus]

Я сам не знаю всех этих протоколов. Чисто на интуиции думаю.
Подразумевается, что один из телефонов известен другому. Например все клиенты должны знать телефонный номер сервера. В вашей задаче можно считать, что один из телефонов - сервер, а другой (или даже другие) - клиент. Проблема только в том, что сервер должен отсылать СМС, а он-то и не знает номер клиента.

Ситуация:
Один телефон регистрируется и получает IP. После он отправляет СМС с этим IP на сервер, телефонный номер которого он знает. Сервер после этого тоже регистрируется и уже через GPRS протокол (не знаю PPP или что-то ещё) отсылает на полученный им IP пакет данных. В этом пакете будет содержаться его собственный IP (сервера). Ну и далее они гоняют данные друг другу.

Если всё ПО писать под себя, то я бы вообще не стал вводить такое жёсткое разделение на клиент/сервер между двумя телефонами. Который первый инициировал соединение - тот и является клиентом. А изначально оба телефона могут быть равноценными.

Не, блин, я туту прикинул SMS может и через день прийти(раз на раз не приходится). Тут важна стабильность. Так что будет сервер в Интернете, через который будет по GPRS происходить обмен IP.
Использование звонков и SMS лучше оставить.

Сообщение отредактировал Yuriy_Rus - Jul 26 2006, 06:04

[GetSmart]

Слушайте, товарищ, я же писал, что вариант с СМС неидеальный, а вариант с дозвоном на пару сек очень хорош. При этом соединение устанавливается за несколько секунд. Все необходимые операции для этого умеет делать любой GPRS модем. Как собственно и любой телефон с GPRS. Да и команды для этих операций стандартизированы и должны поддерживаться всеми модемами.

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

[Chupakabra]

На счет dynDNS - там много вариатнов есть. Бесплатный: когда терминал получает доступ через GPRS в интернет (все сотовые операторы предоставляют только доступ в интернет по технологии GPRS), он посылает http запрос на сайт dyndns.org или аналогичный, содержащий свой IP, имя пользователя пароль на обновление. Далее при запросе через интернет по адресу terminal1.dyndns.org (да хоть с PC обычного) служба DNS обращается к DNS домена dyndns.org, а тот возвращает текущий IP адрес terminal1.
Платные сервисы основаны на обновлении записи в DNS сервере службы dyndns. Это DNS для быстроты обработке можно указать в настройка TCP/IP : primary, secondory. (про платные сервисы я толком не знаю, если нужно думаю сами можете почитать и разобраться что они там предлагают).

На счет надежности всего это дела могу сказать, что надежней всего стало бы наличие собственного сервера 24online заточенного только под обработку запросов c terminal1-N

[zltigo]

Сначала модем посылает свой динамический IP серверу. Затем принимает IP другого. Всё то же самое делает и другой модем.

Если есть сервер, то и работайте ВСЕГДА через него и не морочте голову. Это между прочим ЕДИНСТВЕННЫЙ универсальный вариант. Ибо даже обмеявшись полученными IP вы удручающе высокой
вероятностью обменяетесь ЛОКАЛЬНЫМ IP адресом внутренней сети провайдера, от котогого никакого
толку за пределами сети не будет и если провайдер не полный лох, то доступа не будет и к другим IP
(за исключением Gateway/Proxy/DNS) в его сети.
Посему ВСЯ работа через сервер, или оплата (многие провайдеры сие предоставляют) реального фиксированного IP для ваших модемов.

[Yuriy_Rus]

to Chupackabra

Я уже несколько раз говорил, что будет свой сервер 24online.

Сначала модем посылает свой динамический IP серверу. Затем принимает IP другого. Всё то же самое делает и другой модем.

Если есть сервер, то и работайте ВСЕГДА через него и не морочте голову. Это между прочим ЕДИНСТВЕННЫЙ универсальный вариант. Ибо даже обмеявшись полученными IP вы удручающе высокой
вероятностью обменяетесь ЛОКАЛЬНЫМ IP адресом внутренней сети провайдера, от котогого никакого
толку за пределами сети не будет и если провайдер не полный лох, то доступа не будет и к другим IP
(за исключением Gateway/Proxy/DNS) в его сети.
Посему ВСЯ работа через сервер, или оплата (многие провайдеры сие предоставляют) реального фиксированного IP для ваших модемов.

Так что теперь и общаться модемам только через сервак?
А в случае если они будут использовать одного и того же провайдера?

Сообщение отредактировал Yuriy_Rus - Jul 26 2006, 10:52

[GetSmart]

Yuriy_Rus 11 минут назад Отправлено #33
Группа: Участники
Сообщений: 0
Регистрация: 24-07-06
Пользователь №: 19 039

Это как так? Сообщений = 0 !!!

А в случае если они будут использовать одного и того же провайдера?

Думаю тут 100% можно напрямую.

Ибо даже обмеявшись полученными IP вы удручающе высокой
вероятностью обменяетесь ЛОКАЛЬНЫМ IP адресом внутренней сети провайдера, от котогого никакого толку за пределами сети не будет и если провайдер не полный лох, то доступа не будет и к другим IP (за исключением Gateway/Proxy/DNS) в его сети.

Что за бред? GPRS предоставляет доступ в глобальную сеть. Поэтому и айпишники он выдаёт глобальные. Точно такие же как и при dial-up'е.

[zltigo]

Что за бред? GPRS предоставляет доступ в глобальную сеть. Поэтому и айпишники он выдаёт глобальные.

Незнание азбуки IP - для доступа в глобальную сеть не нужно иметь глобальный IP.
Вот я прямо сейчас пишу с машины которой выдан адрес
192.168.4.102. Заходите в гости :-)

Думаю тут 100% можно напрямую.

Повторяю - если провайдер не без царя в голове (читай - сеть у него сделано не так, как у Вас "во дворе"), то доступа к другим машинам будет закрыт.

[Chupakabra]

Так что теперь и общаться модемам только через сервак?
А в случае если они будут использовать одного и того же провайдера?

Думаю что работа GPRS сети аналогична dialup-у. Каждий клиентский IP может общаться напрямую только со шлюзом, а уж он решает куда разрешать маршрутизацию/NAT трансляцию. Самый плохой вариант когда 1) у 2х клиентвов вобще приватные IP вида 10.0.0.1-2 (mask 255.255.255.0); 2) при этом может быть запрещена маршрутизация 10.0.0.1 <-> 10.0.0.2. Многое из этого уже написал zltigo


Вот уж где надо спецов по GPRS звать

[zltigo]

Так что теперь и общаться модемам только через сервак?

А какая проблема? Если сервак при любом раскладе будет?
Собираетесь 100000 абонентов одновременно соединять и хотите на мощности сервера сэкономить?
Несколько десятков соединений любая 386 потянет.

Так что теперь и общаться модемам только через сервак?

А какая проблема? Если сервак при любом раскладе будет?
Собираетесь 100000 абонентов одновременно соединять и хотите на мощности сервера сэкономить?
Несколько десятков соединений любая 386 под первым попавшемся Linux потянет.

Вот уж где надо спецов по GPRS звать

Это не облась GPRS, а решение системных администраторов конкретного провайдера.

[Chupakabra]

Вот уж где надо спецов по GPRS звать

Это не облась GPRS, а решение системных администраторов конкретного провайдера.

Ну я имел ввиду уровень ниже, т.е. возможности и основы функционирования самого GPRS. Или tcp/ip так плотно интегрирован с ним, что рассмотрение можно ограничить только tcp/ip протоколами?

[zltigo]

Ну я имел ввиду уровень ниже, т.е. возможности и основы функционирования самого GPRS. Или tcp/ip так плотно интегрирован с ним, что рассмотрение можно ограничить только tcp/ip протоколами?

Чего-то я не понял :-(. Интеграции нет и по этой причине можно автономер разбираться с IP..
Что касается архитектуры GPRS/IP, то есть старенький, но зато перезентационный обзорчик
от "Архитектора" сети BT:
http://ripe.net/ripe/meetings/ripe-37/pres...prs/sld001.html

[3.14]

От части схожее обсуждение http://electronix.ru/forum/index.php?showt...=10552&st=0
Мне вот что интересно, в случае работы через DNS по динамическим IP ...
Сколько потребуется времени чтоб вновь присвоенный IP к определенному имени "расползся" по другим DNS серверам, а то получится хотя новый IP и линкован к имени а попасть можно будет на него будет например через сутки (имеется ввиду по имени а не по IP)?

[kuguar]

блин. длинная тема. еслия понял нужно соединить два модема по gprs напрямую. вариант с выделением имени тут я думаю не прокатит потому что как правило ОпСоС выдает динамический адрес но он fake, то есть нереальный и не маршрутизируемый глобально. если соединять два модема из одной сети - то по идее поглядев ип адреса и если они из одной подсети - связать из можно, если из разных то наврятли. вариант - поднять на обоих gprs и попробовать пингануть друг друга. при создании какого то масштабного проекта какие то вещи обсуждаемы на уровне ОпСоС, например - выделение абонентам из корпоративного договора пула реальных айпи. а насчет "расползания" - я так понимаю днс-имя зарегят на определенный ip, который принадлежит подсети которая принадлежит провайдеру, которые прописан в RIPE. соотвественно dns не знающий соответствыя вашего имени-ип полезен на dns именно вашего провайдера.

[zltigo]

Мне вот что интересно, в случае работы через DNS по динамическим IP ...
Сколько потребуется времени чтоб вновь присвоенный IP к определенному имени "расползся" по другим DNS серверам, а то получится хотя новый IP и линкован к имени а попасть можно будет на него будет например через сутки (имеется ввиду по имени а не по IP)?

А никто и не будет динамически имена переприсваивать! Вам временно выдали IP из пула ПРИНАДЛЕЖАЩЕГО не Вам - с чего это Вы взяли, что хоть какой-то DNS пойдет не на сервер владельца
спрашивать "назначенное" ему имя :-). В случае, если это Ваш пул адресов, то тогда конечно вы можете указать какой из ВАШИХ серверов отвечает за привязку и с ним играться. Степень "расползания" может быть ограничена пожеланием другим серверам всем всегда обращаться к Вашему серверу, что однако не помешает кому-нибудь (тем более не серверу) на это наплевать и закэшировать.
Короче, об именах забудьте, либо "назначайте" из прямо на пользовательской машине в hosts - тут
Вам никто не указ :-)

[Yuriy_Rus]

Ну я имел ввиду уровень ниже, т.е. возможности и основы функционирования самого GPRS. Или tcp/ip так плотно интегрирован с ним, что рассмотрение можно ограничить только tcp/ip протоколами?

Чего-то я не понял :-(. Интеграции нет и по этой причине можно автономер разбираться с IP..
Что касается архитектуры GPRS/IP, то есть старенький, но зато перезентационный обзорчик
от "Архитектора" сети BT:
http://ripe.net/ripe/meetings/ripe-37/pres...prs/sld001.html

Решил всё-таки попробовать вариант с обменом IP между модемами с одинаковым провайдером.
Если не выйдет воспользуюсь вашей идеей, и всё будет через сервер.

[kuguar]

точно! можно использовать имя host'а то есть динамическое имя которое присваивает провайдер при подключении. Но оно каждый раз может быть разное. или могут быть еще какието подводные камни. но если провайдер не проводит фильтрацию какую либо то:
1. оба модема поднимают gprs и определяют свои host -имена
2. обмениваются ими (csd или sms) один из них или оба пытаются установить соединеие с друг другом.

[zltigo]

если соединять два модема из одной сети - то по идее поглядев ип адреса и если они из одной подсети - связать из можно

Уже писал - тоже маловероятно, если провайдер нормальный. Дело в том, что это ведь не Ваша сеть на работе/дома(в квартире), где все компьютеры по определению должны видеть и работать друг с другом. Тут вариант гостинницы, где временно встречаются со своими компьютерами разные НЕЗНАКОМЫЕ даже люди и даже будучи подключенными в одну сеть они из соображений безопасности НЕ ДОЛЖНЫ иметь возможность выходить на другие компьютеры постояльцев, да и на компьютеры владельцев гостинницы тоже :-).

[kuguar]

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

[3.14]

Мне вот что интересно, в случае работы через DNS по динамическим IP ...
Сколько потребуется времени чтоб вновь присвоенный IP к определенному имени "расползся" по другим DNS серверам, а то получится хотя новый IP и линкован к имени а попасть можно будет на него будет например через сутки (имеется ввиду по имени а не по IP)?

А никто и не будет динамически имена переприсваивать! Вам временно выдали IP из пула ПРИНАДЛЕЖАЩЕГО не Вам - с чего это Вы взяли, что хоть какой-то DNS пойдет не на сервер владельца
спрашивать "назначенное" ему имя :-). ...

Ну вот например, мое устройство коннектится своим GPRS-ом к сети оператора и тот дает динамический реальный IP, я сообщаю свой новорожденный IP "специализированному" DNS серверу который линкует меня с именем trtrtr.hrhrhr.ru. Далее, человек где-нить в никарагуа пытается достучаться до этого trtrtr.hrhrhr.ru, запрос с его DNS по невероятной цепи доходят до моего DNS, в итоге коннект устновлен можно работать. Проходит какое то время, снова плдключаю свое устройство, получаю другой IP, снова регистрируюсь на нужном DNS. Опять человек из никарагуа хочет попасть по trtrtr.hrhrhr.ru, и ведь тут-то должен наступить полный облом, т.к. в кешах, скорее всего не одного DNS, пока будет фигурировать старый IP ... В итоге все как-то не предсказуемо получается ...
Или я где то ошибаюсь?

[kuguar]

однако ман DNS надо. про несколько серверов fff.ru nnn.com на одном ip я знаю. а наоборот - вопрос интересный. Тут пахнет типа распределенной системой, однако насколько я знаю процедуру регистрации адреса - там указывается один ip. Процедура регистарции - это не настолько автоматизированный процесс, чтобы зная протокол на один и тот же адрес в течении пары(10, 100) минут перегистрировать на разные динамические ip. Эрго - соответствие dns-имени и 1 стат ип необходимо.
1. имеем 2 реальных ип 111(статический реальный) и 222(причем 222 может быть динамический и даже fake)
2. согласно процедуре регистрации имени производим регистрацию ццц.мну.ком на 111 (как здесь описано например http://noc.tomsk.ru/DNS-application.txt )
3. на этом серванте который по идее 24-onair поднимаем socks для себя и входное для друга из Никарагуа
4. когда линк 111<->222 поднят ты с другом общаешься нормально.
5. когда линка нет - друг из Никарагуа получит чтото типа "no 3.14 on air!" которое скажет ему сервер 111
6. когда 111 в дауне - по http например друг получит no route to host.

[zltigo]

я сообщаю свой новорожденный IP "специализированному" DNS серверу который линкует меня с именем trtrtr.hrhrhr.ru.

Уже писал - никакой DNS сервер не примет от Вас (вопросы взлома обсуждать не будем)
"линковку" имени к IP за которым прописан ОФИЦИАЛЬНЫЙ DNS сервер.

Далее,

И никакого "далее" уже обсуждать не надо..

А если позволят на "официальном" менять, то действительно:

В итоге все как-то не предсказуемо получается ...

Хотя можете поставить свой собственный абсолютно автономный не завязанный на общий систему
DNS сервер и сообщив _его_ конкретный IP адрес в Никакрагуа, при условии сброса кэша на никарагуанской машине перед каждым сеансом - получите результат.

[Yuriy_Rus]

если соединять два модема из одной сети - то по идее поглядев ип адреса и если они из одной подсети - связать из можно

Уже писал - тоже маловероятно, если провайдер нормальный. Дело в том, что это ведь не Ваша сеть на работе/дома(в квартире), где все компьютеры по определению должны видеть и работать друг с другом. Тут вариант гостинницы, где временно встречаются со своими компьютерами разные НЕЗНАКОМЫЕ даже люди и даже будучи подключенными в одну сеть они из соображений безопасности НЕ ДОЛЖНЫ иметь возможность выходить на другие компьютеры постояльцев, да и на компьютеры владельцев гостинницы тоже :-).

Вы были правы. Короче, останавливаюсь на варианте, когда весь поток сообщений будет проходить и рассылаться через сервер. Уже решил, что модемов в системе будет больше 2. Т. е. будет идентификация на серваке(по индивидуальному номеру SIM).
Алгоритм реализации:
Формат сообщения от модема на сервер будет такой: (свой номер SIM)(номер SIM, которой надо передать данные)(данные). Занесение в БД(если в 1-ый раз) или Идентификация на серваке.

Запись о модеме в БД будет содержать:
1. Номер SIM
2. IP
3. Данные, кот. ему нужно отправить.

Далее долбание на сервака(думаю каждые 30 сек. может меньше, может больше) на предмет того, "есть, что для меня"? Формат сообщения на запрос: (свой номер SIM).
В это время другой модем отсылает сообщение: (свой номер SIM). Если в первый раз то заноситься в БД, если второй, то просто идентифицируется, и идёт проверка, есть что для него. Если есть, то отправляется.
Временно собщения на отправку, будут храниться на серваке с привязкой к номеру получателя.
Если модем отключился от GPRS зашёл снова, то меняется его IP в базе.
Базу планирую делать на векторах. Вдруг модемов станет больше.

Проблема в том, что будет идти постояноое долбание сервака на предмет данных для себя. Напряг вообщем.
И с обновлением базы (модем поменяли или SIM, и всё, запись просто висит) то же не всё понятно. Через 2 месяца всё удалять и формировать занаво что-ли?

Может у кого другие идеи на счёт алгоритма есть?
Но всё же кто нибудь пробовал разменять модемы IP, при условии, что у однин моб. оператор, и пообщаться? А то вдруг у на симках какого нибудь оператора и получиться. Или отказаться от этой идеи совсем?

Сообщение отредактировал Yuriy_Rus - Jul 27 2006, 12:04

[Yuriy_Rus]

Хотя можете поставить свой собственный абсолютно автономный не завязанный на общий систему
DNS сервер и сообщив _его_ конкретный IP адрес в Никакрагуа, при условии сброса кэша на никарагуанской машине перед каждым сеансом - получите результат.
[/quote]

Это реально? Или за...бистое занятие?

[zltigo]

Может у кого другие идеи на счёт алгоритма есть?

Что за пляски с бубном я не понял совсем :-(
Хотели канал с IP протоколом, так и пользуйте.
Берем примитивный вариант, который потом можете совершенствовать под динамическое выделение ресурсов и удобную идентификацию.
Пишем "сервер" на котором активизируем 16 сокетов на порты xxx01...xx16.
Каждый из внешних девайсов коннектируется к своему порту и посылает серверу пакетик в которм просит его соединить с девайсом подсоединонным к другому указанному порту. Сервак или соединяет
если тот девайc подключен и тупо пересылая фреймы организует прозрачнейший канал, либо сообщает об отсутствии партнера, либо буферирует фреймы для последующей передачи, либо активизирует
процедуру вызова партнера на связь.. В общем по вкусу и возможностям.

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

Это реально? Или за...бистое занятие?

Совершенно банальный сервис. Проблемы нулевые.

[Yuriy_Rus]

Что - то стрёмно. Держать открытым сокет для каждого нового девайса.
Хотя, что эффективнее, надо подумать. Я в Socket API новичок.

Сообщение отредактировал Yuriy_Rus - Jul 27 2006, 13:30

[GetSmart]

По-моему тут кое-кто кое-что не понял.

Допустим есть провайдер, предоставляющий dialup. За ним глобально зарегистрированы допустим сотня айпишников. Если я звоню правайдеру и лезу в сеть, то он даёт мне один из этих айпи на время и я пока сижу на телефоне его имею. То есть нигде их в рилтайме регистрить не надо. Они уже зарегистрированы, закэшированы и оплачены. Короче говоря, в GPRS может быть такая же система, а может быть так, как молвит zltigo. Кто поставит експеримент, тот и узнает.

[zltigo]

Что - то стрёмно. Держать открытым сокет для каждого нового девайса.

Абсолютно ничего стремного, кроме того можете, как я писал держать только один на всех для
авторизации и динамческого выделения/открытия рабочих.

Кто поставит експеримент, тот и узнает.

Эксперимент по отношению к конкретному оператору ставится безумно легко любым, кто имеет доступ к GPRS с телефона - просто выходите через своего любимого провайдера в интернет и смотрите выданный IP.
Он будет почти наверняка из диапазона 10.0.0.0 ... 10.255.255.255
Или другой (менее вероятно) private сети. О приватном диапазоне в каждом из классов сетей
можете справиться в RFC1918. Глобальные и фиксированные адреса общепринято выдавать за отдельную абонентскую плату.
Все выше написанное не есть предположения, а опыт.

[kuguar]

могу предложить следующий вариант - ты говорил что неудобно постоянно долбится на сервер за своей информацией. а что мешает повесить к серверу еще один модем на CSD. У сервера появилась инфа для модема xxx, он звонит по CSD на него (тот трубу не берет а определяет что это сервер) и отсоединяется. Модем , зная реальный айпи сервера соединяется, представляется , и сервер вываливает ему информацию. Что мы имеем - соединение , за которе платится деньги, только в случае если есть информация.

[GetSmart]

Гениально!

Не, сурьёзно

kuguar зарабатывает 10 гринов.

[Chupakabra]

Гениально!

Не, сурьёзно

kuguar зарабатывает 10 гринов.

Быстродействие такой системы удовлетворяет ? )

Вся обсуждаемая "мутотень" предпологала довольно оперативный обмен информацией, а тут получается "але барышня"

А под это дело у опсоса нельзя арендовать реальные IP просто. У мтс помоему такое есть. Да и опсоса думаю есть шанс подобрать специально ?

[GetSmart]

Дак конечно, коннект напрямую был бы идеальным вариантом. Но ведь тут некоторые так правдоподобно говорят, что это невозможно. А если всё-таки соединяться через сервак, то вариант kuguar'а идеальней всего. Тем более, что абонентов может быть немеряно.

[Chupakabra]

Дак конечно, коннект напрямую был бы идеальным вариантом. Но ведь тут некоторые так правдоподобно говорят, что это невозможно. А если всё-таки соединяться через сервак, то вариант kuguar'а идеальней всего. Тем более, что абонентов может быть немеряно.

Чем "немеренней" абонентов, тем менее оперативный обмен будет по архитектуре kuguara. Но вариант вобще достойный (для дешевой системы)

[zltigo]

могу предложить следующий вариант - ты говорил что неудобно постоянно долбится на сервер за своей информацией.

Кто-нибудь ответит, зачем "долбится", если установив канал можно держать его "вечно" и переданная
информация "сама" прилетит. При развале - переустановить.
Или это какие-то Российские гримасы, типа платы за время GPRS соединения а не за трафик на такое поведение толкают?

[Yuriy_Rus]

могу предложить следующий вариант - ты говорил что неудобно постоянно долбится на сервер за своей информацией.

Кто-нибудь ответит, зачем "долбится", если установив канал можно держать его "вечно" и переданная
информация "сама" прилетит. При развале - переустановить.
Или это какие-то Российские гримасы, типа платы за время GPRS соединения а не за трафик на такое поведение толкают?

И это вариант хороший. Однако, программная реализация всех эти планов заставляет задуматься.
Держать на серваке несколько модемов.
Держать несколько "установленных каналов".
Организовывать пересыл сообщений по этой куче каналов.
Подскажи, пожалуйста, (хотя бы вообщем) как енто воплотить в жизнь программно.

[zltigo]

Держать несколько "установленных каналов".
Организовывать пересыл сообщений по этой куче каналов.
Подскажи, пожалуйста, (хотя бы вообщем) как енто воплотить в жизнь программно.

Если речь иде не об embedded решении для сервера, то абсолютно любая
операционка Win-Linux-..... На которой запушена описанная ранее функция реализованная
на штатном интерфейсе BSD совместимых sockets.

[Yuriy_Rus]

Держать несколько "установленных каналов".
Организовывать пересыл сообщений по этой куче каналов.
Подскажи, пожалуйста, (хотя бы вообщем) как енто воплотить в жизнь программно.

Если речь иде не об embedded решении для сервера, то абсолютно любая
операционка Win-Linux-..... На которой запушена описанная ранее функция реализованная
на штатном интерфейсе BSD совместимых sockets.

Нет сейчас хочу замутить сервак на Си в Винде (чтобы с алгоритмом разобраться, проблемы реализации порешать, проверить как оно всё работает, отладить и сделать как можно эффективнее). Я просто енто лучше всего знаю. А затем буду преобразовывать под BSD.

Сообщение отредактировал Yuriy_Rus - Jul 28 2006, 06:38

[zltigo]

Нет сейчас хочу замутить сервак на Си в Винде (чтобы с алгоритмом разобраться, проблемы реализации порешать, проверить как оно всё работает, отладить и сделать как можно эффективнее). Я просто енто лучше всего знаю. А затем буду преобразовывать под BSD.

А разница при портировании будет минимальнейшая, особенно если WIN расширений sockets не пихать без всякой на то надобности.

[Yuriy_Rus]

А разница при портировании будет минимальнейшая, особенно если WIN расширений sockets не пихать без всякой на то надобности.

Тем более тестовый вариант буду делать в Винде на Си.
Так что с реализацией как программно замутить несколько активных каналов?

[zltigo]

Так что с реализацией как программно замутить несколько активных каналов?

??? А как один - понятно? Тогда сделайте это столько раз, сколько нужно...

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

[Yuriy_Rus]

Так что с реализацией как программно замутить несколько активных каналов?

??? А как один - понятно? Тогда сделайте это столько раз, сколько нужно...

Смысле в единичный момент времени будет только 1 канал между 2 девайсами?
Или можно сделать несколько активных каналов? Если да, то как?

[zltigo]

Или можно сделать несколько активных каналов? Если да, то как?

ТАК-ЖЕ КАК И ОДИН, НО НЕСКОЛЬКО РАЗ.

[Yuriy_Rus]

bool cycle = 0; INT32 Soc;
//-----------------------------------------------------------------------------
void Connect()
{
int Soc1;
SOCKADDR_IN Sin1;
int Sin1len = sizeof(Sin1);
Soc1 = accept(Soc,(struct sockaddr*)&Sin1, &Sin1len); //функция извлечения будет висеть пока не получит клиента
if(Soc1 <= 0)
{
Application->MessageBox("Ошибка при извлечении из очереди запроса на соединение!", "Ошибка...", MB_OK+MB_ICONERROR);
}
else
{
char* Ipbuf = inet_ntoa(Sin1.sin_addr); //номер узла сети
AnsiString a2 = Ipbuf;
int b = htons(Sin1.sin_port); //номер порта
AnsiString Message = "Принято соединение с " + a2 + " " + IntToStr(;

Application->MessageBox(Message.c_str(), "Сообщение...", MB_OK+MB_ICONINFORMATION);

BYTE RecvErrorBuffer[1];


char RecvBuffer[20];
while(recv(Soc1, RecvErrorBuffer, sizeof(RecvBuffer), 0)!= SOCKET_ERROR)
{
// printf("%c", RecvBuffer[0]);
recv(Soc1, RecvBuffer, sizeof(RecvBuffer), MSG_DONTROUTE);
}


// тут идентификация, обработка данных на отправку на другой девайс, сохранение и т. д.

closesocket(Soc1);
}
}
//-----------------------------------------------------------------------------
void __fastcall TfServer::B_WaitngModeClick(TObject *Sender)
{
//
Soc = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
if(Soc == -1)
{
Application->MessageBox("Ошибка работы функции создания Socket!", "Ошибка...", MB_OK+MB_ICONERROR);
}
else
{
SOCKADDR_IN Sin;
Sin.sin_family = AF_INET;
Sin.sin_port = htons(80);
Sin.sin_addr.s_addr = INADDR_ANY; /

int Bnd;
Bnd = bind(Soc, (LPSOCKADDR)&Sin, sizeof(Sin));
//(LPSOCKADDR)&Sin - указывает на структуру данных, содержащую локальный адрес, приписываемый socket'у (для TCP/IP)
if(Bnd == -1)
{
Application->MessageBox("Ошибка при определении локального адреса канала связи со средой!", "Ошибка...", MB_OK+MB_ICONERROR);
}
else
{

int Lstn;
Lstn = listen(Soc, SOMAXCONN);
// SOMAXCONN - определяет максимальную длину очереди входящих запросов на установление связи
if(Lstn != 0)
{
Application->MessageBox("Ошибка при ожидании запроса!", "Ошибка...", MB_OK+MB_ICONERROR);
}
else
{
// do
// {
Connect();
// }while(cycle == 0);
}
}
}
}

//-------------------------------------------------------------------------------------------------------------------
Вот общий каркас сервака с одни рабочим сокетом, к которому все цепляются, делают своё "чёрное дело" и отцепляются.
Как он (сервер) будет держать несколько сокетов и несколько девайсов на них?
Как будет организовываться пересыл данных между девайсами на разных сокетах?
Как будет оганизовано пересыл между несколькими парами устройств?

[zltigo]

Вот общий каркас сервака с одни рабочим сокетом, к которому все цепляются, делают своё "чёрное
дело" и отцепляются.

Извините, не стал читать, или как принято сейчас выражаться "ниасалил" :-)

Как он (сервер) будет держать несколько сокетов и несколько девайсов на них?

Может Вы не понимаете, что сокетов может быть открыто по числу ПОРТОВ на стороне сервера?
Или я тогда вообще НИЧЕГО не понимаю, чего Вы не понимаете :-(

Как будет организовываться пересыл данных между девайсами на разных сокетах?

Вычитали содержимое из одного сокета и тупо запихнули его в другой.

Как будет оганизовано пересыл между несколькими парами устройств?

А чем "это" отличается от пересылки между одной парой?
Проблема схожая с открытием второго сокета?

Настойчиво повторяю:

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

[Yuriy_Rus]

[quote name='zltigo' date='Jul 28 2006, 12:38' post='138697']
[quote]
Можете почитать для затравки исходники чего-либо простого, например, TFTP сервера.
Там уже будет соединение с выделенным портом, сообщение "чего хочу", достижение "консенсуса"
и по достижении оного выделение личного сокета для последующей работы. Останется только выбросить протокол пересылки файла заменив его пересылкой между подключившимися клиентами.
[/quote]

Не подскажите где можно найти эти исходники на Си.

[zltigo]

Не подскажите где можно найти эти исходники на Си.

Линуксовые приблуды - самый очевидный источник.
Самый простой поиск в интерненте по "TFTP server sources"...

[bullit]

to Yuriy_Rus

Может это тебе поможет: http://electronix.ru/forum/index.php?showtopic=18634 - второй пост, прикрепленный файл. Только там про реализацию, а не про программу, но тоже думаю поможет.

[zltigo]

Как ни странно Free Talks

Может не стои повторять ошибку?

[Yuriy_Rus]

Как ни странно Free Talks

Может не стои повторять ошибку?

Господа вы это о чём?

На счёт системы пересыла данными.
Я на днях снова вернулся к рассмотрению данного вопроса, и меня можно сказать осинило.
ОпСоСы уже давно реализовали данную проблему - ММС сообщения. Это и есть данные, которые пересылаются между GPRS модемами. И насколько меня информировали они это делают через свой сервер (не напрямую между телефонами).

Но что я сомневаюсь, что они на своём сервере держат новый сокет под каждую трубу, вышедшую в GPRS или всё так и есть? Если нет расскажите мне, пожалуйста про схему, которую используют ОпСоСы.

Ещё один момент, zltigo предлагал схему, в которой модемы постоянно висят в GPRS. Но я тут опять пораскинул всем, чем есть, и осознал что если телефон долгое время не активен в сети, то его банально обрубают, т. е. нужен "постоянный" трафик. Временной интервал у разных ОпСоСов, насколько мне известно разный, думаю примерно 10-15 минут (экмпериментов не ставил, если кто-то ставил сообщите, пожалуйста). А организовывать постоянный трафик не хочется, тем более, что это маленькие, но всё же деньги.
Товарищ zltigo, вы что думаете по этому поводу?

[zltigo]

Господа вы это о чём?

О неудачном первоначальном выборе Вами раздела для своего сообщения.

И насколько меня информировали они это делают через свой сервер (не напрямую между телефонами).

Естественно.

Но что я сомневаюсь, что они на своём сервере держат новый сокет под каждую трубу, вышедшую в GPRS или всё так и есть?

На время процесса передачи да. В вашем случае речь шла о КАНАЛЕ, что есть совсем другое, нежели
обмен сообщениями. Если Вас устраивает обмен сообщениями - SMS и MMS в Вашем полном распоряжении.

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

За что это вдруг? Провайдерский произвол? Кстати, обычно существует и плата за соединение. Учтите.

[Yuriy_Rus]

Провайдерский произвол?

Да, РОССИЯ одним словом.
Хотя в рамках решения данной задачи, думаю, надо произвести испытания на этот счёт Мегафона, МТС и ПчелинойЛинии хватит.

[Yuriy_Rus]

При всём при том, что ММС и есть яркий пример, обмена информацией между сервером ОпСоСа(интернетом) и абонентом(трубой) по GPRS каналу. Т. е. там вроде(сам не пробовал, а надо бы)
такая система: сервак отправляет СМС трубе, мол для тебя есть ММС. Тот принимает решение качать или не качать. Если качать, то труба выходит в GPRS, получает свой дин. IP и лезит на сервер за своей ММС, а сервак отправляет.

Никто не знает енто всё так и есть?

[Yuriy_Rus]

to zltigo

Не подскажете это имелось в виду передача данных по GSM или нет.
//--------------------------------------------------------------------------------------------
Ярежим передачи данных. Вот АТ команды:

at+cbst=7(9600 скорость),0,0(или 0(авто),0,0) - скорость, прозрачность, сжатие
at+fclass=0 - режим передачи данных
atd<номер телефона>

ждем около 15 сек соединение, т.е. ответ CONNECT <speed> и через пару сек отправляем че хотим.

А приемник только получает и нечего там настраивать не надо.

Так соединяются два модема. Может даже конференц связь
//--------------------------------------------------------------------------------------------

[zltigo]

Не подскажете это имелось в виду передача данных по GSM или нет.

Улыбки не понял. Это не GPRS.
Если устраивает оплачивать время по тарифам речевого соединеия - используйте.
Скорость обычно 9600. Некоторые првайдеры при хорошем канале разрешают занимать до 14400 из общей GSM полосы 19200. Для входящего модемного звонка требуется обычно отдельный номер за
дополнительную плату. Есть еще у некоторых провадеров HSCSD c занятием нескольких каналов там
уже десятки килобит.

[Yuriy_Rus]

Сейчас занимаюсь отладкой написанной системы клиент-сервер-клиент.
Всё построено на Socket API.
Не могу разобраться с одним касяком:
После recv на сервере просматриваю принятый буфер, а он пустой!?
Коннект клиента к серваку проходит точно.
В чём может заключпться ошибка работы этой функции?
recv(soc, RecieveBuf, D_BufLength, 0)

[Shadow_ru]

По поводу сокетов на сервере :

1 Listening сокет и всё. Зачем изобретать лисапеды ?
Yuriy_Rus - асинхронные сокеты вы будете долго осиливать, ей богу.
Ставим Апач + cgi, либо Томсат. Пользуем HTTP протокол.
В данной конфигурации - самое оно, плюс имеет уже отлаженые либы.

По поводу ММС имею сказать следующее.

Оператор присылает мобиле Push WAP сообщение по SMS каналу, в котором находится URL, на который необходимо обратиться.
Мобила поднимает GPRS канал и по HTTP(sic!) каналу лезет за информацией.

[Yuriy_Rus]

По поводу сокетов на сервере :

1 Listening сокет и всё. Зачем изобретать лисапеды ?
Yuriy_Rus - асинхронные сокеты вы будете долго осиливать, ей богу.
Ставим Апач + cgi, либо Томсат. Пользуем HTTP протокол.
В данной конфигурации - самое оно, плюс имеет уже отлаженые либы.

По поводу ММС имею сказать следующее.

Оператор присылает мобиле Push WAP сообщение по SMS каналу, в котором находится URL, на который необходимо обратиться.
Мобила поднимает GPRS канал и по HTTP(sic!) каналу лезет за информацией.

Спасибо за участие в обсуждении и информацию, однако "лисапед" я уже изобрёл. Сервер написал по схеме, предложенной уважаемым zltigo. На Winsock2.h всё работает идеально. Остаётся приступить к работе с модемами, но тут у меня локальные проблемы.
Кстати, вы не знаете стандартные AT+ команды, кот. позволяют произвести PAP авторизацию?

[kuguar]

я думаю что это уже уровень другой- авторизация - по OSI - уровень приложения. Поищи в инете описание протокола авторизации PAP, почитай http://old.osp.ru/pcworld/2001/04/151.htm , http://www.protocols.ru/modules.php?name=C...age&pid=139 и RFC1334.

[Shadow_ru]

РАР авторизацию - проводит стек IP/PPP дров , по крайней мере в Винде/Линуксах так.

[Shadow_ru]

Yuriy_Rus, почитал тут ваши посты.
Вы желаете провести поднятие РРР соединения и авторизацию модемом?
Если честно, никогда не слышал о такой гайке.
Знаете почему ?
1) РРР - УНИВЕРСАЛЬНЫЙ протокол. И реализуется соответсвенно на кочнечных устройствах, а не на средствах передачи данных.
2) Потому, что в момент установления РРР соединения там ещё проходят LСP пакеты, которыми задётся ваш личный IP адрес, плюс могут указываться DNS. И что с этими пакетами будет делать модем ?
Сохранить в угол, а потом клеить в заголовки IP пакетов ?
P.S. И ещё вопрос - каким образом в ваших оконечках будет храниться адрес сервера. Неужели в виде IP адреса?

[Yuriy_Rus]

Yuriy_Rus, почитал тут ваши посты.
Вы желаете провести поднятие РРР соединения и авторизацию модемом?
Если честно, никогда не слышал о такой гайке.
Знаете почему ?
1) РРР - УНИВЕРСАЛЬНЫЙ протокол. И реализуется соответсвенно на кочнечных устройствах, а не на средствах передачи данных.
2) Потому, что в момент установления РРР соединения там ещё проходят LСP пакеты, которыми задётся ваш личный IP адрес, плюс могут указываться DNS. И что с этими пакетами будет делать модем ?
Сохранить в угол, а потом клеить в заголовки IP пакетов ?
P.S. И ещё вопрос - каким образом в ваших оконечках будет храниться адрес сервера. Неужели в виде IP адреса?

Модем со своей задачей справляется и через гипер-тер. в GPRS выходит. У него есть ряд спец. АТ команд, кот. задают точку доступа, имя и пароль польз. И ещё одна спец. команда, кот. через полученные данные выходит в GPRS, проходя PAP авторизацию(на практике работает точно, можете не сомневаться).

в момент установления РРР соединения там ещё проходят LСP пакеты, которыми задётся ваш личный IP адрес, плюс могут указываться DNS. И что с этими пакетами будет делать модем ?
Сохранить в угол, а потом клеить в заголовки IP пакетов ?

Вот про енто пожалуйста попотробнее всей этой технологии не знаю... Особенно интересуют "LСP пакеты".
P. S. Да в виде IP-адреса. И всё в цвет работает, но пока на локалке и на Winsock, а не на модемах.

[Yuriy_Rus]

Ещй вопрос по программированию COM.
Какая-то лажа...
При запуске компа я запускаю свою прогу и через неё по СОМ пытаюся получить или передать данные - Ничерта, всё виснет.
Затем пускаю гипертерминал, ввожу там команду, закрываю его, снова запускаю прогу, и уже всё Ок, данные отправляються и передаются.
Подозреваю, что всё дело в настройках СОМ-порта. Но я вроде всё, что надо для модема в проге учитываю и в DCB всё запихиваю (скорость, чётность, биты данных, стоповые биты, управление потоком).

[GetSmart]

zltigo
Вот я сейчас с берегов чёрного моря в инете через GPRS выхожу и мой айпишник совсем не похож на тот, который Вы говорили. Это почему?

ЗЫ вот что у меня в аське написано:
External IP=83.149.24.98
Internal IP=172.16.3.121

[zltigo]

Вот я сейчас с берегов чёрного моря в инете через GPRS выхожу и мой айпишник совсем не похож на тот, который Вы говорили. Это почему?
External IP=83.149.24.98
Internal IP=172.16.3.121

Это мы очем? О глобальных IP?
1. Я не в курсе, что и о чем там Аська пишет - посему ipconfig /all и информацию по GPRS интерфейсу сюда.
2. Никто не запрещает выдавать глобальные адреса, как и не ОБЯЗЫВАЕТ их выдавать. Мысль понятна?
3. Вы сейчас находитесь в несколько необычных условия роуминга а там есть два принципиально разных варианта "простой" - когда Ваш трафик терминируют по месту прописки и тогда с локальным IP возможны варианты и "правильный" - когда провайдер роуминга у себя терминирует.
4. Вернетесь домой - посмотрите.

[GetSmart]

zltigo
Не. карточка Мегафоновская и я её здесь местную купил. Так что никакого роуминга нету.

А как узнать реальный (ну или какой другой) айпи? Какой прогой?

[zltigo]

zltigo
А как узнать реальный (ну или какой другой) айпи? Какой прогой?

ipconfig /all и информацию по GPRS интерфейсу сюда.

[zltigo]

ЗЫ вот что у меня в аське написано:
External IP=83.149.24.98
Internal IP=172.16.3.121

Кстати, на самом деле вопрос в Вашем случае можно считать закрытым,
поскольку трудно на самом деле толковать "Internal IP=172.16.3.121"
иначе, как выданный Вам IP.
А 172.16.0.0/16 это именно и есть приватная сеть "B" класса - спите спокойно,
к Вам никто снаружи не придет :-)

[GetSmart]

Код

Настройка протокола IP для Windows 2000

        Имя компьютера  . . . . . . . . . : starbob
        Основной DNS суффикс  . . . . . . :
        Тип узла  . . . . . . . . . . . . : Широковещательный
        Включена IP-маршрутизация . . . . : Нет
        Доверенный WINS-сервер  . . . . . : Нет

Адаптер Megafon GPRS:

        DNS суффикс этого подключения . . :
        Описание  . . . . . . . . . . . . : WAN (PPP/SLIP) Interface
        Физический адрес. . . . . . . . . : 00-53-45-00-00-00
        DHCP разрешен . . . . . . . . . . : Нет
        IP-адрес  . . . . . . . . . . . . : 172.16.45.190
        Маска подсети . . . . . . . . . . : 255.255.255.255
        Основной шлюз . . . . . . . . . . : 172.16.45.190
        DNS-серверы . . . . . . . . . . . : 83.149.24.244
                                            62.183.50.230

[goodwin]

Долгонько тут идет обсуждение очевидного...
Тщательно изучал этот вопрос когда-то. Пришел к одному выводу - только выделенный сервер в сети со статическим адресом для обмена. Все остальное - изврат...
И еще: сейчас модем без поддержки IP - раритет... Никаких PPP, LCP, PAP, CHAP реализовывать в своих дивайсай нет смысла - все есть в модемах по $40...
Проще всего GET, PUT на HTTP сервер посредством AT команд... На сервере - обрабатываюший запросы скрипт.
Если объем данных небольшой, то самое выгодное (в России) - сеансное соединение устройств к серверу через пчелайн GPRS, ибо у них первые 5 кБ не тарифицируются... Халява
Срочный вызов дивайса для сеанса обмена можно осуществить простым дозвоном с сервера.
Постоянная связь съедает трафик за счет флуда, который постоянно присутствует в приватной сети оператора (правда немного, если не отвечать на ICMP, сканировние DCOM маздая и пр.). В пчелайне в приватной сети - каша...
Поддерживать постоянное соединение невыгодно и еще по одной причине - случайные обрывы, и связанный с этим перерасход трафика (Допустим набежало 10 кБ, обрыв... оператор при этом слупляет тарифный минимум - 49 кБ... И так далее ) Так, что сеанс дешевле в смысле накладныхрасходов.
Надеяться например на то, что пчелайн в Казани и пчелайн в Москве - одна и та-же сеть не стОит - даже с IP вида 172.x.x.x на обеих модемах - это разные подсетки. Проверить легко - при соединении с сервером прописывается IP пчелайновского маршрутизатора - один на всех...
Маршрутизатор некоторое время хранит информацию о соединении - то бишь можно пользовать не только TCP, но и UDP. Пакеты ходят туда и обратно - проверено... (шлем с модема UDP пакет на сервер, потом можно ответить UDP пакетом на IP адрес сотового маршрутизатора - доходит..) Хотя TCP все-таки надежнее.

Вот такие наблюдения...

ЗЫ: Выделенный сервер по нынешним временам не роскошь - обыденность... Например в наших краях сейчас идет акция - ADSL подключение вместе с "проводами до дома" за 300 руб Сам модем стОит 27 баксов... Ну и хиленький пентиум для полного счастья... Я при пробах пользовал (с нулевыми познаниями в PHP, CGI и пр.) бесплатную утилиту "Small HTTP Server " - всего 17 кБ !!! И простейший консольный обработчик HTTP CGI запросов на дельфях...

[Shadow_ru]

2Yuri_Rus

Ну, гипертерминал наверное сигналы RTS,CTS поднимает, у вас управление потоком - аппартное в гипере стоит ?.

2 goodwin.
О! Верным путём идёте товарищ.

Про IP почему сказал. Ну вы взяли себе выделенку, а провайдер возми, да поменяй пул IP адресов. Делают они так, не часто но бывает.
Так-что если по IP - лучше иметь 1 сервак + 2 прозрачных редиректора на других провайдерах.
Чтобы было время свои железки на новый IP перешить.

А GPRS модемы у меня всегда были только в виде мобил Siemens. Там такого счастья не было. APN задать - да, РРР - не видел.
Всё-же я себе слабо представляю, как модем САМ! строит IP пакеты из сырого потока данных и рассылает их со всеми верными полями в заголовке + режет поток данных по частям. А потом обратно раскручивает.
Как-то реализовывал РРР на ISDN, очень муторное занятие. Очень.

Сообщение отредактировал Shadow_ru - Aug 25 2006, 05:07

[zltigo]

IP-адрес . . . . . . . . . . . . : 172.16.45.190
Маска подсети . . . . . . . . . . : 255.255.255.255
Основной шлюз . . . . . . . . . . : 172.16.45.190

Ну вот - обычное дело - грамотно построенная сеть (можете мои предыдущие посты перечитать), резюме:
1. Выдан приватный адрес для подсетей класса "B" - из глобального интернета не зайдете.
2. Для Вас создана своя локальныая сеть из одного компьютера - "соседи" - за бетонной стенкой.

[goodwin]

2 goodwin.
О! Верным путём идёте товарищ.

Уже давно никуда не иду

По поводу встроенного сэка можно глянуть : http://www.macro-peterburg.ru/pdf/TCP-IP%2...Note%201.01.pdf

[goodwin]

IP-адрес . . . . . . . . . . . . : 172.16.45.190
Маска подсети . . . . . . . . . . : 255.255.255.255
Основной шлюз . . . . . . . . . . : 172.16.45.190

Ну вот - обычное дело - грамотно построенная сеть (можете мои предыдущие посты перечитать), резюме:
1. Выдан приватный адрес для подсетей класса "B" - из глобального интернета не зайдете.
2. Для Вас создана своя локальныая сеть из одного компьютера - "соседи" - за бетонной стенкой.

Увы, для пчелайна необычное
Пытался звонить - разводят руками - ничего не можем(не хотим?) сделать...
Они видимо заинтересованы, чтобы в подсетке был постоянный трафик.
Короче раздолье для служб мастдая/вирусни...