нет, у тебя может и клиент и сервер упасть

Если падает сервер - не работает никто. Если падает клиент - переподключается.

>Если падает сервер - не работает никто.

Если падает сервер - не работает никто. Если падает клиент - переподключается.

но откуда ты знаешь, получил ли он сообщение или нет

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

отсюда придется городить ack модель

но откуда ты знаешь, получил ли он сообщение или нет

Эм... В смысле? Разве протокол TCP не гарантирует 100% доставку данных? А при обрыве подключения - писал выше.

Эм... В смысле? Разве протокол TCP не гарантирует 100% доставку данных? А при обрыве подключения - писал выше.

он гарантирует порядок доставки и валидность пакетов)

О.О

но эт не гарантия остального

Эм... В смысле? Разве протокол TCP не гарантирует 100% доставку данных? А при обрыве подключения - писал выше.

Задача о двух генералах.

Пауза. Я в гугл.

в принципе, можешь не возвращаться

в принципе, можешь не возвращаться

Токсично. Как скалисты прям.

Токсично. Как скалисты прям.

спасибо за комплимент, скоро в скала чате буду своим в доску

Dmitrii? как только перестанешь про котлин писать, то может быть)

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

блин, не пали(

Ростислав, а можно услышать то что от тебя хочет заказчик?

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

разве

Вообще все ТЗ писать долго. Как минимум, потому что оно очень абстрактно и охватывает аспекты, о которых сейчас речь не идет.

разве

Самый логичный вариант. Нафиг они тогда нужны, если данные могут не прийти?

Вообще все ТЗ писать долго. Как минимум, потому что оно очень абстрактно и охватывает аспекты, о которых сейчас речь не идет.

т.е. ТЗ нет

и анализа не было

Да. Примерно так. ?

Ты расскажи кто есть клиенты сколько их, что им нужно.

еще вопрос, а почему заказчик не обратился в серьезную фирму? а все доверил 1 человеку?

очевидно же что не имелся в виду реалтайм, а просто относительно быстрая доставка новых данных

так нельзя же додумывать вопрос!

Школьнику

Школьнику

да вот же

Потому что так дешевле. Я же уже когда-то сюда писал, что я Android-разработчик и вообще школьник? :)

Потому что так дешевле. Я же уже когда-то сюда писал, что я Android-разработчик и вообще школьник? :)

ну раз так, то делай как умеешь

потом приходи, будем думать, если что пойдет не так

Ещё раз говорю, распиши что от тебя хочет заказчик

Стоит ли говорить, что заказчик "Ашот".

так нельзя же додумывать вопрос!

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

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

Был.

Ещё раз говорю, распиши что от тебя хочет заказчик

Сейчас.

Пойдем лучше в learn.jvm или лс, так как этот процесс будет засорять чат.

Пиши

да норм, тут таргетинг выше

остаёмся тут

Ок.

я чувствую, до джавы мы не дойдем, тут бы анализ провести

а и еще совет, я заметил, что ты хочешь прям сесть

и сразу все идеально написать

так не бывает

А жаль...

сесть на стул с пиками хочешь)

делай сначала PoС, потом Demo, потом пробуй продукт

вот для пока вообще пофиг на чем, главное проверить видение заказчика

1. "Пиши как умеешь" - плохой вариант. Лучше узать, как правильно и научиться так писать. 2. "Потом будем думать, если что-то не заработает" - построй дом, а если упадет, потом построим фундамент.

1. "Пиши как умеешь" - плохой вариант. Лучше узать, как правильно и научиться так писать. 2. "Потом будем думать, если что-то не заработает" - построй дом, а если упадет, потом построим фундамент.

Ты не узнаешь как правильно, пока сам какашку не напишешь.

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

1. "Пиши как умеешь" - плохой вариант. Лучше узать, как правильно и научиться так писать. 2. "Потом будем думать, если что-то не заработает" - построй дом, а если упадет, потом построим фундамент.

ну т.е. ты думаешь за 1 день научиться строить и понимать, как люди, которые годами работают. как в этом чате?

Даже не так, ты не поймёшь как правильно.

Ты посмотрел на то что тебе сказал заказчик и составил какое то уже своё представление о нагрузке и требование. Мне лично кажется что твоё требование не соответствует действительности.

ну т.е. ты думаешь за 1 день научиться строить и понимать, как люди, которые годами работают. как в этом чате?

Но толкнуть же в правильном направлении вы сможете.

Ты посмотрел на то что тебе сказал заказчик и составил какое то уже своё представление о нагрузке и требование. Мне лично кажется что твоё требование не соответствует действительности.

я бы еще добавил к анализу, что идет додумывание за закачика

а ведь ему ничего не показали еще

Тебе нужно сесть и написать конкрентно что от тебя хочет заказчик: какие клинеты, какую роль они выполняют, что им нужно, какие еще роли есть

чтобы он фидбэк оставил

может админам будет похер, и они будут кликать на кнопку, чтобы получить актуальные данные

а мы тут рил тайм лепим

ERROR: S client not available

Тебе нужно сесть и написать конкрентно что от тебя хочет заказчик: какие клинеты, какую роль они выполняют, что им нужно, какие еще роли есть

с этим можно приходить и рассуждать уже о возможных вариантах решения

Короче, проверь бизнес-идею, распиши, что сказал Павел, потом делай как умеешь и на чем хочешь Proof of Concept

показываешь Ашоту

собираешь фидбэк

а потом думать надо

показываешь Ашоту

и он тут же его на шашлык

и он тут же его на шашлык

или наоборот, "ВАЙ БРАТ ОТ ДУШИ СДЕЛЯЛЬ"

Ты посмотрел на то что тебе сказал заказчик и составил какое то уже своё представление о нагрузке и требование. Мне лично кажется что твоё требование не соответствует действительности.

Дано: система такси предприятия. 90 таксистов и 10 администраторов + неограниченное число пользователей. Таксист - это урезанная версия администратора. В сумме обоих называю клиентами. Нужно: чтобы пользователи могли делать заказы на машину. У водителя должна быть возможность принять этот заказ. У администратора должна быть возможность принять этот заказ и удалить этот заказ. В данный момент логика такова: 1. Поступает заказ от пользователя. 2. Заказ отображается у клиентов. 3. Клиент производит какое-либо действие. 4. Заказ удаляется (или автоматически по заданному таймауту, или вручную администратором). Каждый пункт содержит много нюансов, но концепция такая. Реалтайм я пытаюсь впихнуть во 2-й пункт, чтобы на 3-м пункте все дружно не пытались произвести какое-либо дейтсвие на принятом заказе.

Оп... А чего выделение на ПК не работает.

может админам будет похер, и они будут кликать на кнопку, чтобы получить актуальные данные

Это уже называется сделать на от*бись, если честно.

Это уже называется сделать на от*бись, если честно.

пожалуйста, не читай через 1 сообщение

я совсем другое писал

а еще в твоей писанине выше, путаница в терминологии

у тебя админ, клиент, пользователь

Это уже называется сделать на от*бись, если честно.

Он все так делает, лул

тебе заказчик дал этот сервер кастрированный или что?

где ты его взял? почему ты думаешь что тебе его хватит?

тебе заказчик дал этот сервер кастрированный или что?

Да...

а почему твой заказчик считает что его будет достаточно?

Я говорил и говорю, что этого мало, но, руководствуясь фазой луны, как говорится...

а почему твой заказчик считает что его будет достаточно?

а почему ты считаешь, что этого будет недостаточно? Может, сначала сделать, а потом по мере нужды добавлять память? Или ты думаешь, что джаве много не бывает? Дать ей 30 гигов оперативки, ну а чо, с запасом

Ладно, не в сервере дело. Это уже отдельная проблема, которую я решу, если не хватит.

Дано: система такси предприятия. 90 таксистов и 10 администраторов + неограниченное число пользователей. Таксист - это урезанная версия администратора. В сумме обоих называю клиентами. Нужно: чтобы пользователи могли делать заказы на машину. У водителя должна быть возможность принять этот заказ. У администратора должна быть возможность принять этот заказ и удалить этот заказ. В данный момент логика такова: 1. Поступает заказ от пользователя. 2. Заказ отображается у клиентов. 3. Клиент производит какое-либо действие. 4. Заказ удаляется (или автоматически по заданному таймауту, или вручную администратором). Каждый пункт содержит много нюансов, но концепция такая. Реалтайм я пытаюсь впихнуть во 2-й пункт, чтобы на 3-м пункте все дружно не пытались произвести какое-либо дейтсвие на принятом заказе.

Не говори слово реалтаим

Исходя из того, что выше (я не про Ника):

Чего-то мне начинает казаться, что я иду не в том направлении. Может подскажите. Вечером сажуть писать функцию, не хочу начать делать не в том направлении. Дано: сервер, на котором содержится список заказов. Заказы постоянно добавляются/удаляются/изменяются. Изменения могут проходить где-то раз в секунду на один заказ (посредством HTTP запросов), заказов может быть от 100 до 1000. То есть 100-1000 изменений в секунду. У сервера 2 ядра по 2 потока, 100/100 мбит скорость. Задача: моментально отображать изменения заказазов в клиентских программах (до 100 машин). Планируется: с каждым клиентом устанавливать NIO соединение (через сокеты Netty), в которое изменения будут поступать потоком сериализованных объектов. После чего, на клиентах, будут разбиваться на категории и отображаться в таблицах JavaFX. Вопрос: правильный ли мой подход к решению поставленной задачи? Не будет ли просиданий в производительности или задержек?

Дано: система такси предприятия. 90 таксистов и 10 администраторов + неограниченное число пользователей. Таксист - это урезанная версия администратора. В сумме обоих называю клиентами. Нужно: чтобы пользователи могли делать заказы на машину. У водителя должна быть возможность принять этот заказ. У администратора должна быть возможность принять этот заказ и удалить этот заказ. В данный момент логика такова: 1. Поступает заказ от пользователя. 2. Заказ отображается у клиентов. 3. Клиент производит какое-либо действие. 4. Заказ удаляется (или автоматически по заданному таймауту, или вручную администратором). Каждый пункт содержит много нюансов, но концепция такая. Реалтайм я пытаюсь впихнуть во 2-й пункт, чтобы на 3-м пункте все дружно не пытались произвести какое-либо дейтсвие на принятом заказе.

У водителя должна быть возможность принять этот заказ. У администратора должна быть возможность принять этот заказ я не понял

Лучше сказать реактивно)

а почему ты считаешь, что этого будет недостаточно? Может, сначала сделать, а потом по мере нужды добавлять память? Или ты думаешь, что джаве много не бывает? Дать ей 30 гигов оперативки, ну а чо, с запасом

убунту 300 мб на системые процессы сожрёт. не уверен что на оставшиеся можно сделать похожую систему.

У водителя должна быть возможность принять этот заказ. У администратора должна быть возможность принять этот заказ я не понял

Все правильно. Водитель - это администратор, без функций удаления заказов. Поэтому я их называю обобщенно клиентами.

Все правильно. Водитель - это администратор, без функций удаления заказов. Поэтому я их называю обобщенно клиентами.

лучше называть их водителями

к тому же известно что при 100% нагрузки jvm на пользу не идёт