| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Как организовать одновременное чтение из COM-порта
kami © (2008-06-04 23:38:00)Вечер добрый.
Столкнулся с такой задачей:
имеется устройство, подключенное к COM-порту и программа, получающая из него данные. Необходимо дать возможность получения этих данных как другими модулями самой программы (с чем проблем, в принципе, нет), так и другими процессами (созданы на Delphi, мной), причем их количество заранее неизвестно. Нужно только чтение, запись не предусмотрена де-юре и де-факто.
На данном этапе имею возможность организовать "распараллеливание" чтения данных при помощи установки виртуальных COM-портов, по паре на каждого "читателя". Но...это на мой взгляд неправильно.
В идеале хотелось бы видеть такую картину : 1 модуль работает непосредственно с портом, а остальные модули/процессы регистрируют в этом модуле callback-функции и "забывают" о необходимости каких-то там настроек портов и тому подобном.
Подскажите пожалуйста, правильно ли мне видится "идеал", и как такое лучше/правильнее сделать.
Evgeny V (2008-06-06 13:08:00) [21]
> sniknik © (06.06.08 12:35) [45]
Подтверждение о приеме пакета по TCP формируется ситемой независимо от клиента, для этого ему даже не обязательно вызвать recv. Подтверждение о расшифровке пакета, о работе с протоколом уровня приложения -это уже дело клиента, но оно не всегда нужно или не на каждый пакет. Это зависит от задачи. В случае рестрансляции байтов от СOM порта, от программы-сервера не требуется играть роль клиента приложения или устройства подключенного к порту и являющегося источником данных. Это транспорт, считай виртуальный виртуальный COM порт своего рода. Если клиент должен послать какое-либо подтверждение программе идли COM порту это дело клиента. Если мы только читаем данные - то клиент только принимает и ничего не посылает и сам ничего не подтверждает. АСК по TCP клиентское приложение не делает, это делается мимо него. Для приложения сервера в этом случае все выглядит так - послал пакет, ждешь следующий для отправки. На приеме стоишь для проверки "живости соединения", для тех случаев когда есть значительная пауза между данными с порта. Да код несколько больше чем при UDP клиенте, но не используя бродкаст или мультикаст ты в итоге сделаешь почти то же самое,единственно в случае работы с пакетами UDP проще. А если ты попытаешься сделать "сниффером", то код проще не будет.
Но пакеты не обязательное в случае TCP в некоторых случаях. При определнных условиях достаточно просто завернуть поток с порта на TCP. Насчет использования протокола не по назначению - это зависит от ситуации. Я писал, что на одном компе я и сам скорее использовал бы UDP, но в локале может быть и так, что только TCP.. Зависит от условий задачи. Об этом я тоже писал. И что? в итоге ты меня читаешь внимательно, а я тебя нет? Когда у меня были вопросы в понимании того, что ты написал, я их задал, если где-то понял не верно, то так и написал, Ответа от тебя не получил почти не на один вопрос. От тебя вопросов нет, есть утверждения и предположения.
Slym (2008-06-06 12:45:00) [22]Вообщето IP предназначен для меж "компового" взаимодействия впервую очередь...
для локального решения в первую очередь нужно применять локальные решения такие как OPC, Messages тп и тд, и их высокоуровневые реализации DDE, OLE тп и тд
sniknik (2008-06-06 12:35:00) [23]> Мне очень интересно было услышать о TCP переделанном в UDP - это словосочетание можно назвать абракадаброй....
можно и так.
но я называю это не целевым использованием,
протокол без ожидания ответа использовать нужно именно для пакетов, а протокол с подтверждением доставки (причем обычно не для одного, а целой очереди пакетов - потока данных) именно для потока данных (файлов там, еще чего).
а вот использовать второй для посылки одного пакета и не ждать ответа (т.е. именно то для чего предназначен первый)... вот это и есть "переделка"/не целевое использование/абракадабра....
и занимаешься этим ты. я только предполагаю.
при этом (опять дежавю) если второй протокол использовать по назначению с ответами то с ними придется чтото делать... т.е. лишний код, лишние действия, дополнительная обработка для времени ожидания т.к. в этот период нельзя послать следующий пакет. и т.д. т.е. дополнительный геморрой. ради чего все? про дополнительные факторы, которые вынудят делать именно так, ничего не сказано (а после даже было подтверждение, что их и нет -> [38]).
p.s. наверное достал уже всех повторами... сорри, не смог удержаться.
Evgeny V (2008-06-06 12:12:00) [24]
> Anatoly Podgoretsky © (06.06.08 11:54) [43]
Анатолий, чего ждать - с блокирующим сокетом буду ждать ошибки SOCKET_ERROR, которая может прийти сразу или в течении определенного тайм-аута. При неблокирующем и аснхронном сокете она вернется позже. Но даже если я работаю с блокирующим сокетом, я работаю с ним в отдельном потоке на сервере и ждет этот поток, на работу с другими клиентами это не скажется.
Если вы восприняли мои слова, как-то, что TCP не ждет подтверждения от клиента, то вы просто не внимательно прочитали ветку, а взяли один пост. Разговор шел о том, что работа с одним слиентом не блокирует работу с другими клиентами по TCP, каждый из них работает со своим сокетом. Впрочем вы то это знаете.
Насчет не смогу отказаться - под виндами отказываюсь - закрывая сокет в другом потоке (для блокирующего сокета) и можно в этом же для неблокирующего.
Anatoly Podgoretsky (2008-06-06 11:54:00) [25]> Evgeny V (06.06.2008 11:23:42) [42]
> Я вижу ты не владеешь темой, а потому объяснять, что ошибки при работе с TCP возвращаются в виде кодов возрата фукнций, и ждать на каждый пакет подтверждения от клиента нет необходимолсти ( опять таки зависит от задачи) видимо проблематично, так же у меня возникло сомнение и в том что ты знаешь о тайм-ауте - это я про
Мне кажется, что это ты не владеешь темой, если это код возврата функции, то ты будешь ждать и даже отказаться не сможешь.
Evgeny V (2008-06-06 11:23:00) [26]
> sniknik © (06.06.08 10:55) [41]
> у меня тоже вопрос? а ты то, что я отвечаю вообще читаешь?
> и зачем тогда я "распинаюсь"?
Ты как-то в штыки воспринял вопросы. Там в конце предложений стоял знак вопроса - во такой ?
Я спросил "Ты утверждаешь, что UDP пакет в спящем режиме... " для уяснения для себя на основании твоей фразы
> sniknik © (05.06.08 13:17) [32]
> причем бывало комп долго "прочухивался", до пары минут.
> TCP за это время три раза по таймауту отвалится, а UDP пакет
> просто подвиснет в недрах системы вместе с ней... в итоге
> "гарантированная" доставка в TCP сыграет злую шутку не доставкой
> пакета..., т.к. ты ее сам при таймауте прервешь (следующий
> же надо посылать), или если ты предусмотрел эту ситуацию
> то усложненной обработкой ошибки, и перепосылкой потом.
вроде как раз с целью, что бы понять а не выдергивать из контекста.
> не надо приписывать мне то что я не говорил, я писал что
да согласен - ты не писал, что сделал, ты писал, что рассматривал - извини, мне просто показалось, что делал...
> поздравляю, молодец, сделал иp TCP UDP, читай sniknik ©
> (05.06.08 13:17) [32] почему я это считаю идиотизмом (тогда
> сказал мягче, но теперь...)
Я вижу ты не владеешь темой, а потому объяснять, что ошибки при работе с TCP возвращаются в виде кодов возрата фукнций, и ждать на каждый пакет подтверждения от клиента нет необходимолсти ( опять таки зависит от задачи) видимо проблематично, так же у меня возникло сомнение и в том что ты знаешь о тайм-ауте - это я про
> да, если это протокол TCP не переделанный в UDP, таймаут
> на сервере возникнет, и в период до таймаута у него не будет
> возможности послать следующее пакеты, для таких придется
> организовывать очередь и т.д. можеш начинать сначала (у
> меня стойкое ощущение дежавю).
Мне очень интересно было услышать о TCP переделанном в UDP - это словосочетание можно назвать абракадаброй....
Насчет фальшивого интереса ты прав отчасти. Мне и правда было интересно о том, что может происходить в спящем режиме, я думал у тебя есть такой осмысленный опыт. Потом стало интересно, а что ты можешь сказать еще....
Оставлю многоточия, в надежде, что модераторы не удалят:-)
sniknik (2008-06-06 10:55:00) [27]> то по TCP я плюнул пакети тоже забыл о нем.
поздравляю, молодец, сделал иp TCP UDP, читай sniknik © (05.06.08 13:17) [32] почему я это считаю идиотизмом (тогда сказал мягче, но теперь...)
> Кстати у меня работа сервера из-за кривого сервера ну никак не нарушается.
потому что ты используешь протокол не по назначению.
> Вопросы по спящему режиму:
у меня тоже вопрос? а ты то, что я отвечаю вообще читаешь? и зачем тогда я "распинаюсь"?
> Ты утверждаешь, что UDP пакет ...
я не утверждаю, я высказывал предположения обьясняя изза чего сделал бы так а не иначе.
сомневаешься - проверь. напиши тест (можно взять "индийский" пример), одну прогу с посылкой другую с прослушкой, прослушивающую запусти из IDE поймай пакет с точкой останова внутри обработки, не отпуская (эмуляция "слиапа/тормоза") пошли еще несколько, отпусти... сделай выводы. (я кстати не пробовал, предположение чисто на "логике", так что у тебя есть хорошая возможность меня опровергнуть)
> или будет сформирован с такой задержкой что на сервере возникнет ошибка тайм-аута?
да, если это протокол TCP не переделанный в UDP, таймаут на сервере возникнет, и в период до таймаута у него не будет возможности послать следующее пакеты, для таких придется организовывать очередь и т.д. можеш начинать сначала (у меня стойкое ощущение дежавю).
> Ты писал, что сделал в свое время прием ...
не надо приписывать мне то что я не говорил, я писал что
> когдато я рассматривал такую задачу, из интереса.
а не сделал, до сделал насколько помню не дошло, обошелся утилитой от Русиновича.
и кстати я там же писал
> не помню подробности
добавлю. и не хочу вспоминать... не занимаюсь этим сейчас. другие задачи. так что вопросы по конкретике, как там и что...
ты вообще как читаешь? вообще ктонибудь ответы читает(не дергает цитаты а именно смысл)? никогда не удавалось чтото обьяснить... еще с того почему не следует ADOQuery использовать для команд, т.к. есть ADOCommand для этого. не, ктото читающий говорил после что сделал выводы, но ни одного из спорящих отстаивающих ADOQuery убедить не удавалось... не хотят. все обьяснения разбиваются о "тупо-равнодушное" "но у меня работает же. и почему тогда ADOCommand лучше?".
здесь, имхо, видится что то подобное, замаскированное фальшивым интересом типа "а убедите ка меня". и еще раз имхо это невозможно, обьяснить тому кто понимать не хочет. посему прекращаю любые обьяснения. в этой ветке точно, в других посмотрим.
Evgeny V (2008-06-06 06:33:00) [28]
> sniknik © (05.06.08 16:08) [37]
> как раз таки спасет, т.к. нет взаимодействия с клиентом
> (ожидания ответа), сервер "выплюнул" пакет, хоть в кривой,
> хоть в нил хоть в бездну, и забыл про него тутже. работа
> не нарушится.
Извини, если речь о кривом клиенте, то по TCP я плюнул пакет и тоже забыл о нем. Не клиент дает ACK на пакет, а система...
> ага, и говорить ты это надо авторам нормальных клиентов
Кстати у меня работа сервера из-за кривого сервера ну никак не нарушается. Проблемы кривого клиента его проблемами и остаются.
> ну вот теперь тема оказывается UDP vs TCP
> хотя изначально я объяснял (пытался) почему я бы сделал
> именно так. не более.
А я не против UDP или TCP/ Я просто изначально не понял аргумент о спящем клиенте... и TCP В связи с чем прошу все таки уточнить, так как я не не знаю работы машины в спящем или ждущем режиме...
Вопросы по спящему режиму:
1)
Ты утверждаешь, что UDP пакет в спящем режиме будет принят системой и потом из ее "недр" передан клиентскому приложению?
2) Могу ли я понять твои слова о TCP для спящего клиента так, что возможно пакет будет принят системой, но ACK на него не будет сформирован или будет сформирован с такой задержкой что на сервере возникнет ошибка тайм-аута?
3) И еще, если ты это пробовал - а как ведет себя прием данных напрямую из COM порта на "спящем клиенте", есть ли потери данных в этом случае?
И вопрос по сети:
Ты писал, что сделал в свое время прием на одной машине UDP пакетов по одному адресу и по одному порту. как? Если из разряда снифферов -ioctlsocket ( sock , SIO_RCVALL... - то вопрос отпадает.
sniknik (2008-06-05 19:38:00) [29]> Но - см. предыдущий абзац про "состыковку" UDP клиентов/серверов.
а никто не ограничивает тебя одним протоколом... инициализацию/закрытие можеш на другом сделать, каком удобнее, хош на TCP, а хочеш вообще по https...
для инициализации, вернее авторизации/логине клиента на сервере как раз протокол с подтверждением и возможностью послать ответ по открытому каналу намного удобнее "безответного". иначе, если этого нет, то придется самому делать, что тоже лишний код.
kami (2008-06-05 19:09:00) [30]Спасибо всем за обсуждение.
> Германн © (05.06.08 01:36) [10]
> Нифига. Все данные пишутся в лог. И при следующем подключении
> выдаются клиенту.
Нифига :) Нет необходимости, данные утрачивают свою актуальность через 1-3 секунды после получения их из порта.
> sniknik © (05.06.08 01:55) [11]
> аварийная ситуация - к клиентам долго не обращались, они
> все ушли в спячку
Так же невозможно - после инициализации устройства пакетные данные идут постоянно 4 раза в секунду, размером по 50-100 байт и так и будет продолжаться до выключения устройства, а с ним и всех обрабатывающих программ (да, этого не было в [0], но изначально я искал общее решение, которое можно будет применить не только в этой задаче. Но, для общего решения - абсолютно верно, нужно будет это предусматривать).
> Evgeny V © (05.06.08 11:27) [20]
> Про UDP - бродкаст или мультикаст? Это хорошо, посылаем
> один раз и всем. Хорошо работает на одной машине, в локальной
> сети
Локальная сеть не предусматривается - все на одной машине. Хотя, тут я уже противоречу себе - по поводу "общего" решения.
> sniknik © (05.06.08 11:44) [23]
> речь как раз и шла про одну машину, а на ней, одной, кучу
> клиентов слушающих один порт организовать трудновато.
Кстати, да - из того, что мне доступно - передавать по UDP могут только TXXXUDPClient. Соответственно, у каждого модуля, которому нужны эти данные, должен быть TXXXUDPServer. А на одной машине... я смогу это сделать только по количеству сетевых интерфейсов, привязав каждый UDPServer к одному из них. А в общем случае - количество нуждающихся в данных неограничено. В дополнение - как Com-port_модуль узнает, что ему нужно создать(али уничтожить) TUDPтраляля, чтобы отдавать данные какому либо модулю? С TCP делаем проще (imho, просто я больше всего работал с TServer|ClientSocket) - у модуля, работающего с COM-портом ставим TXXXServerSocket, а остальные, которым нужны данные подключаются с помощью TXXXClientSocket. Нужно - подключился, не стало нужно - отключился. В дополнение можно привязать TServerSocket к 127.0.0.1, чтобы никакая бяка не подцепилась. Где я ошибаюсь?
Вопрос действительно не стоит в обязательности/необязательности какого-либо протокола(тьфу, и я туда же :) ), выбор уже сделан - сокеты, как общее решение для меж... в общем, взаимодействия. Осталось только выяснить - какие. С UDP действительно - гораздо проще обрабатывать, так как данные приходят пакетами(меньше кода - меньше вероятность ошибок и т.д), в TCP это дополнительная обработка. Но - см. предыдущий абзац про "состыковку" UDP клиентов/серверов.
sniknik (2008-06-05 16:08:00) [31]> Ок - в этом случае это проблема клиента и его прикладного уровня.
ага, и говорить ты это надо авторам нормальных клиентов, объясняя почему изза неправильной работы одного клиента нарушилась работа сервера. хотя, изначально речь шла не нарушениях работы, а о затруднении обработки для того же результата. (а то опять придерутся...)
> От кривого клиента UDP тоже не спасет.
как раз таки спасет, т.к. нет взаимодействия с клиентом (ожидания ответа), сервер "выплюнул" пакет, хоть в кривой, хоть в нил хоть в бездну, и забыл про него тутже. работа не нарушится.
> плюс и минус ни тому ни тому протоколу не идет в этом случае:-)
ну вот теперь тема оказывается UDP vs TCP
хотя изначально я объяснял (пытался) почему я бы сделал именно так. не более.
Evgeny V (2008-06-05 15:47:00) [32]
> sniknik © (05.06.08 15:29) [35]
> т.е. ты пишешь под "частный случай", у тебя чегото нет,
> ты считаеш что этого нет вообще.
Я такого не говорил, что такого нет вообще, и даже не высказывал сомнения, правда их имею, ибо не знаю. Но это решается опытным путем:-)
Я конечно знаю, что компьютер выключают, но код для такого общего случая, который работал бы на выключенном компе я еще писать не умею:-) (шутка)
Если есть опыт, поделись - это серьезно, если есть что сказать - напиши статью для сайта, почитаю с интересом, да и сайту будет полезно и людям. Тема -работа с сетью, с БД (или что-то еще) в спящем.ждущем режиме компьютера. Или просто разработка приложений с учетом .... и т.п.
> смотрим вопрос. нет такого условия. разве невозможно предположить,
>
> что и посылки неравномерные и стендвай не отключен?
Условия нет, это просто своего рода Keep Alive на уровне приложения - вещь весьма полезная надо сказать. Если данные к тебе приходят и ты посылаешь свои данные успешно, то проверять связь необходимости нет, а если возникла пауза - то рекомендуется периодически через какое-то время это делать.
> забудь про все "сложные" для тебя обьяснения, максимально
> простое - клиент писал криворукий программист, вместо того
> чтобы ответить вовремя его программа в это время скажем
> пихала иконку в трей. далее то что написано.
Ок - в этом случае это проблема клиента и его прикладного уровня. Я вообще делаю посылку keep alive в своем классе сокета cкорее для транспортного уровня - что бы получить ошибку SOCKET_ERROR или не получить ее, а прикладной уровень и кривой клиент проткол проверяется уже на уровне протокола между клиентом и сервером. Это ошибка другого уровня, хотя в частном случае восстановление нормального общения между сервером и клиентом на какой-то срок возможна разрывом соединения. От кривого клиента UDP тоже не спасет. плюс и минус ни тому ни тому протоколу не идет в этом случае:-)
sniknik (2008-06-05 15:29:00) [33]Evgeny V © (05.06.08 14:29) [33]
> просто не случалось
т.е. ты пишешь под "частный случай", у тебя чегото нет, ты считаеш что этого нет вообще.
> в моем случае не реже раз в 10 сек
смотрим вопрос. нет такого условия. разве невозможно предположить, что и посылки неравномерные и стендвай не отключен?
> Вот про подвисание пакетов на приеме в стандбае я честно говоря опять не понял, куда делись пакеты , почему они подвисли
забудь про все "сложные" для тебя обьяснения, максимально простое - клиент писал криворукий программист, вместо того чтобы ответить вовремя его программа в это время скажем пихала иконку в трей. далее то что написано.
tesseract © (05.06.08 14:55) [34]
> А потоки то тут причём ?
не причем. читай все, не выдирай из контекста... (tread <> stream)
p.s. нафиг. надоело. воистину чем больше объяснений тем тем больше простора буквоедам... читать местами и докапываться. а не понимать смысл.
tesseract (2008-06-05 14:55:00) [34]
> TCP это потоковые данные, протокол сделан кстати на основе
> UDP,
TCP выполняет установку "сеанса" UDP нет, UDP может игнорировать CRC, TCP нет. А потоки то тут причём ?
Evgeny V (2008-06-05 14:29:00) [35]
> sniknik © (05.06.08 13:17) [32]
Машина у меня просто не выключается месяцами, ночью на ней может никто не работает (на некоторых работают 24*7), но много активных задач и сервисов.
В такой "стендбай" машина и диск у меня не попадали, просто не случалось, да и у нас на "рабочих лошадках" спящий режим просто не включен (на некоторых монитор может выключаться)
Программы крутятся и обращение есть постоянно. COM порт что-то принимает, даже если есть пауза, то сокеты по 10 секундному тайм-ауту отсутствия данных (активности), шлют проверочные сообщения, для того что бы знать, что соединение не умерло, а потому доставка есть или ее нет. Данные с порта получаю по разному, чаще всего пакетом и тут есть момент, что и отправлять лучше пакетом и на получении лучше собирать в пакет (ИМХО), хотя для ретранслятора это и не есть обязательное условие ибо пакет или последовательность пакетов тоже можно представить потоком. Да и поток собрать - я посылаю пакеты через send сокета, что для UDP, что для TCP.(ну для UDP бывает SendTo). Кстати для TCP в этом случае, может быть полезен алгоритм Nagle - но это опять надо смотреть по задаче.
Вот про подвисание пакетов на приеме в стандбае я честно говоря опять не понял, куда делись пакеты , почему они подвисли, даже если диск остановился (уснул). Я что-то не знаю видно. Мне так казалось, что если задача активна, регулярно что-то шлет (в моем случае не реже раз в 10 сек), а реально чаще, то вроде такой ситуации возникнуть не должно.. Но честно говоря про стандбай я не могу ничего сказать - не знаю.
Я так понимаю, что в таком случае надо запрещать диску уходить спячку. В любом случае это не есть рабочий режим, если такое происходит, то и UDP не гарантирует правильной доставки. А то, что TCP может в этом случае потерять связь я считаю даже за плюс, есть повод помигать оператору красной лампочкой на экране, мол поставщик данных отвалился и попытаться реанимировать соединения. В данном случае считаю это плюсом для TCP:-) (а вот то, что границы сообщения четко определены - это плюс к UDP) :-)
sniknik (2008-06-05 13:17:00) [36]> А что такое заснул?
никогда машину надолго включенной не оставлял? когда проги к которым не обращаются уже скидываются в своп, а диск уходит в "стендбай" (или как там называется, останавливается в общем), потом подходишь чегото нажимаешь и он начинает медленно со скрипом "просыпаться"...
у меня из такого состояния удавалось проги которые "однозапускные с проверкой по мьютексу" две, три штуки запустить (даже виндовый диспетчер задач). вот, это оно.
причем бывало комп долго "прочухивался", до пары минут. TCP за это время три раза по таймауту отвалится, а UDP пакет просто подвиснет в недрах системы вместе с ней... в итоге "гарантированная" доставка в TCP сыграет злую шутку не доставкой пакета..., т.к. ты ее сам при таймауте прервешь (следующий же надо посылать), или если ты предусмотрел эту ситуацию то усложненной обработкой ошибки, и перепосылкой потом.
> Тут я маленько заблудился и извиняюсь не понял идеи.
суть идеи... с COM порта данные получаются пакетами или потоком? у меня пакетами (баркод), значит и пересылка дальше пакетным способом удобнее (1 в 1). все, алес вопрос закрыт. если нет никаких дополнительных факторов, любое изменение будет только усложнять решение. ->
TCP это потоковые данные, протокол сделан кстати на основе UDP, и вот вы получается, что делаете? преобразуете пакет в поток, для передачи его потоковым методом, которому, самому методу, пытаетесь навязать поведение пакетной посылки... имхо, но я нахожу это немного "замудренным".
> Как вариант я считаю имеет место быть и то и другое и третье и возможные еще решения:-)
кто бы с этим спорил, это очевидно.
Anatoly Podgoretsky (2008-06-05 12:53:00) [37]> sniknik (05.06.2008 11:53:29) [29]
А я говорю про нормальные документированые. А то что возможно это и так понятно и путей несколько, только это не наш путь.
Evgeny V (2008-06-05 12:37:00) [38]
> sniknik © (05.06.08 11:45) [25]
Сорри, но словосочетание воспринялось видно как обязательная рекомендация, а был другой контекст.:-)
А что такое заснул? И почему дойдет до UDP не дойдет до TCP клиента? Тут я маленько заблудился и извиняюсь не понял идеи. Я согласен, что UDP может дать определенное преимущество при парсинге сообщений -а что собственно парсить, границы определены, есть и другие удобства...
В прочем сейчас спор - это спор об удобстве и предпочтениях мне кажется. Как вариант я считаю имеет место быть и то и другое и третье и возможные еще решения:-)
sniknik (2008-06-05 11:53:00) [39]да.
Anatoly Podgoretsky (2008-06-05 11:52:00) [40]> sniknik (05.06.2008 11:49:27) [27]
Это хакерские решения.
| |
Страницы: 