Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

DCC2 [ править ]

DCC2 находится в разработке ( статья Slashdot на DCC2 ). Хотя это может подпадать под «расширения» DCC, похоже, что это будет полная замена. Может быть, об этом стоит упомянуть в статье? - Kowh 01:53, 26 апреля 2004 г. (UTC)

Я добавляю примечание о том, что DCC FSERVE доступен только под mIRC. Его нет ни в X-Chat, ни где-либо в семействе ircII. - Куэрво, 01:36, 9 апреля 2005 г. (UTC)

Поправьте меня, если я ошибаюсь, но я не думаю, что FSERV является отдельной службой на уровне DCC, а скорее использует CHAT (или вместо него CTCP) и SEND / XMIT вместе для создания чего-то еще. Этот вид сценариев также не является эксклюзивным для mIRC. Я обновил статью, чтобы отразить это. - Andyluciano, 22 августа 2005 г., 05:33 (UTC)
Это правильно. FSERV использует интерфейс на основе DCC CHAT, чтобы пользователь мог находить и запрашивать файлы, которые затем отправляются через обычную DCC SEND. И, да, это было реализовано под другими клиентами (в некоторых случаях как сценарии, а в некоторых (как с mIRC) как встроенная функция).
Что касается DCC2: он был в разработке несколько лет и почти не собирается никуда идти. По сути, это хорошая идея - полностью отказаться от DCC - ужасного, плохо (и едва ли) спланированного беспорядка. Я не помню его подробностей, но было бы лучше заменить его на гораздо более надежную архитектуру с минимумом (возможно, с использованием scp или другого существующего безопасного туннельного протокола), а не просто новым методом квитирования. (Но я отвлекся, и это не то место.) - StationaryTraveller 14:03, 21 июля 2006 г. (UTC)

CTCP vs. ответ CTCP [ править ]

Поскольку ответ на PRIVMSG не должен быть другим PRIVMSG, ответ CTCP реализуется с помощью NOTICE. Но является ли ответ DCC ACCEPT ответом на ответ, сообщением CTCP или ответом CTCP? Я предполагаю, что это должен быть ответ и реализован с помощью УВЕДОМЛЕНИЯ, но было бы хорошо, если бы это подтвердилось.

IRC-часть подтверждения DCC выполняется полностью как отсутствие ответов CTCP (то есть PRIVMSG). Таким образом, сообщения ACCEPT и RESUME не подчиняются рекомендациям RFC-1459 об автоматических ответах (предназначенных для предотвращения циклических циклов между роботами). Автоматические ответы (любого рода) на УВЕДОМЛЕНИЕ также запрещены (поэтому серверы IRC не жалуются, если вы отправляете УВЕДОМЛЕНИЕ несуществующей цели). Таким образом, диалоги между роботами ограничиваются одним обменом. Одна из основных глупостей DCC заключается в том, что он слишком много делает через IRC, вместо того, чтобы как можно скорее добраться до своего прямого соединения и завершить на нем рукопожатие. - StationaryTraveller 14:15, 21 июля 2006 г. (UTC)

XMIT [ править ]

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

«Стандарт DCC» - это оксюморон  ;) - StationaryTraveller 14:18, 21 июля 2006 г. (UTC)

Библиотеки программирования [ править ]

Разве мы не должны включать что-то о программных библиотеках, доступных для кодирования таких материалов DCC ??

DCC Send Exploit [ править ]

DCC Send Exploit не очень полезен для меня, так как я предположительно пострадал после того, как был уведомлен оператором IRC. В частности, эта часть «Замена [символьный аргумент] строкой из 14 или более символов ...» ничего не значит; где должен существовать этот [символьный аргумент]?

Я считаю, что описание здесь в порядке, за исключением этой необъяснимой части, но ссылка с более подробной информацией была бы действительно полезной. —Предыдущий неподписанный комментарий, добавленный Jimcooncat ( обсуждение • вклад ) 09:35, 6 февраля 2008 г. (UTC)

Я считаю, что в случае с mIRC эта часть вообще больше не нужна, я слышал, что эксплойт больше не существует в последних версиях mIRC. Вот почему я продолжаю удалять его, но другие отменяют мои изменения, что очень раздражает. - Speeddemon8803 ( разговор ) 18:36, 14 мая 2009 г. (UTC)