БП 2.0 и УТ 10.3 не поддерживают управляемые формы и следовательно работу в тонком клиенте.
именно про это я и написал)
Кроме того я бы не сказал что тонкий клиент в обычном режим (не через HTTP) менее требовательный к соединению чем толстый.
ощутимо менее требовательный, особенно к latency. ну по крайней мере, в моей практике на относительно тонких каналах с относительно высоким пингом тонкий клиент в обычном режиме выручал.
а вот если нужен именно толстый, тут да, или доставлять приложение, так или иначе (remoteapp, ulteo, xenapp, etc), или пускать на полноценный терминал.
у 7.7 была такая фишка — что если хоть один из компов клиентов тугой, тупить начинают все. в 8ке этого нет (ну если не свалится в блокировки конечно).
Исключительно дело привычки.
согласен. ну уже не раз и не два звонили люди в ужасе, обновив случайно до 3.0. впрочем, кому-то даже нравится, но их, по крайней мере у меня, меньшинство:)
1с 7.7 была более требовательна к каналу и к железу всех участников работы.
а в 8.х уже придумали тонкий клиент\веб клиент для работы в том числе и через WAN.
одна проблема — в 11 торговле нет порционного учета, а от бух-ии 3.0 бухи сходят с ума
проглядел про бух2 и торг10.
в режиме толстого клиента будет тормозить ещё и из-за пинга, как уже писали. только в режиме тонкого клиента, ну или доставлять приложение любым удобным способом (remoteapp, xenapp, ulteo, etc)
сталкивался с похожей байдой, тоже грешил на хе и на провайдеров… оказалось проблема в виндовом стеке.
если вы вдруг на серверах под управлением вин2008+ сделали netsh int tcp set global autotuninglevel=disabled, они радостно считают, что у них гигабит и через ван работают паршиво (около 10мегабит как раз выходит). ставим netsh int tcp set global autotuninglevel=enabled (если у вас в инфраструктуре нет 2003 винды) — получаете нормальную скорость (на канале сто мегабит — сто мегабит). если есть 2003-е вёнды — netsh int tcp set global autotuninglevel=highlyrestricted — тогда будет чуть меньше, но всё равно приемлемо (где-то около 80 мегабит).
ну и помните, что микротики без криптомодулей в впн-е не особо производительны.
да, интерфейс непривычный. особенно тяжко переходить со старой прошивки на свежие (или WW) где его перерисовали. зато добавили очень много вкусного, вроде сниффера (раньше был только в консоли) и всяких SSL-VPN.
а вот с остальным не соглашусь, с микротиками я больше глюков ловил, впрочем от софтварного роутера много и не требуется:)
к слову, если освоить консоль DFL, всё становится проще и логичнее, в том числе и веб-интерфейс.
=) спасибо. просто Primo Cache заинтересовал — в плане ускорения дисковой подсистемы в целом, а не ручное распределение горячих и холодных данных. обычных-то рам-дисков как у дурака фантиков, а вот не системного кэша решений других я на шару не нашел (под мс). вдруг кто в продакшене использует:)
Технологическая безработица имеет место быть с изобретения колеса. тут ничего не попишешь — или прогресс и луддиты, или стагнация. В идеальном мире автоматизация не влияет на трудоустройство — сотрудники просто пьют чай с плюшками, а зряплата капает. но у нас капитализм и издержки сокращаются. людей можно жалеть — а можно радоваться, что они не загнивают в теплом местечке, а идут дальше.
изучал этот вопрос… два варианта — или делать прослойку с помощью xvkbd (будет ком-сканер изображать клавиатурный) или использовать библиотеку от 1С, в частности драйвер 1С: Сканеры штрих-кода (NativeAPI).
это я к тому, что не обязательно было сбрасывать роутер. а если бы на точке был человек с 3g-модемом\смартфоном — можно было вернуть всё как было через какой-нибудь teamviewer:)
если кинете в личку конфиги — могу посмотреть. но я думаю, что описание вашей проблемы и решение её есть на форуме микротика.
кстати имхо l2tp для site2site не лучший вариант, я предпочитаю хотя бы ipsec, можно поверх ipip, можно «голый»- это более универсально для связки оборудования разных производителей — не все умеют в gre и т.п
эм… а мак-телнет что не использовали? винбокс замечательно цепляет кротиков в одном броадкаст домене по маку.
очень удобно — грохнул дефолтный конфиг полностью и настраивай в свое удовольствие. разумеется, если нет подготовленного файла с конфигом:)
именно про это я и написал)
ощутимо менее требовательный, особенно к latency. ну по крайней мере, в моей практике на относительно тонких каналах с относительно высоким пингом тонкий клиент в обычном режиме выручал.
а вот если нужен именно толстый, тут да, или доставлять приложение, так или иначе (remoteapp, ulteo, xenapp, etc), или пускать на полноценный терминал.
согласен. ну уже не раз и не два звонили люди в ужасе, обновив случайно до 3.0. впрочем, кому-то даже нравится, но их, по крайней мере у меня, меньшинство:)
а в 8.х уже придумали тонкий клиент\веб клиент для работы в том числе и через WAN.
одна проблема — в 11 торговле нет порционного учета, а от бух-ии 3.0 бухи сходят с ума
в режиме толстого клиента будет тормозить ещё и из-за пинга, как уже писали. только в режиме тонкого клиента, ну или доставлять приложение любым удобным способом (remoteapp, xenapp, ulteo, etc)
если вы вдруг на серверах под управлением вин2008+ сделали netsh int tcp set global autotuninglevel=disabled, они радостно считают, что у них гигабит и через ван работают паршиво (около 10мегабит как раз выходит). ставим netsh int tcp set global autotuninglevel=enabled (если у вас в инфраструктуре нет 2003 винды) — получаете нормальную скорость (на канале сто мегабит — сто мегабит). если есть 2003-е вёнды — netsh int tcp set global autotuninglevel=highlyrestricted — тогда будет чуть меньше, но всё равно приемлемо (где-то около 80 мегабит).
ну и помните, что микротики без криптомодулей в впн-е не особо производительны.
а вот с остальным не соглашусь, с микротиками я больше глюков ловил, впрочем от софтварного роутера много и не требуется:)
к слову, если освоить консоль DFL, всё становится проще и логичнее, в том числе и веб-интерфейс.
а вот 870й интереснее, читаю про него.
без контроллера — только если mesh городить.
если кинете в личку конфиги — могу посмотреть. но я думаю, что описание вашей проблемы и решение её есть на форуме микротика.
кстати имхо l2tp для site2site не лучший вариант, я предпочитаю хотя бы ipsec, можно поверх ipip, можно «голый»- это более универсально для связки оборудования разных производителей — не все умеют в gre и т.п
очень удобно — грохнул дефолтный конфиг полностью и настраивай в свое удовольствие. разумеется, если нет подготовленного файла с конфигом:)