насчет игровых серверов не могу сказать, т.к. не занимаемся подобным, а обыкновенные средненагруженные проекты (web) таких проблем, вроде, не испытывают.
чтоб это проверить нужно знать на какой домен серт выдан.
jur.org.ua продан
старт принят
нет, такого добра не обнаружилось на этих доменах
DC13
PING 98.158.105.234 (98.158.105.234) 56(84) bytes of data. 64 bytes from 98.158.105.234: icmp_seq=1 ttl=57 time=15.0 ms 64 bytes from 98.158.105.234: icmp_seq=2 ttl=57 time=15.0 ms 64 bytes from 98.158.105.234: icmp_seq=3 ttl=57 time=14.7 ms 64 bytes from 98.158.105.234: icmp_seq=4 ttl=57 time=14.9 ms --- 98.158.105.234 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3000ms rtt min/avg/max/mdev = 14.753/14.934/15.024/0.137 ms PING 4.69.139.106 (4.69.139.106) 56(84) bytes of data. 64 bytes from 4.69.139.106: icmp_seq=1 ttl=56 time=15.4 ms 64 bytes from 4.69.139.106: icmp_seq=2 ttl=56 time=15.4 ms 64 bytes from 4.69.139.106: icmp_seq=3 ttl=56 time=15.3 ms 64 bytes from 4.69.139.106: icmp_seq=4 ttl=56 time=15.3 ms --- 4.69.139.106 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 15.334/15.401/15.446/0.097 ms PING 64.125.29.98 (64.125.29.98) 56(84) bytes of data. 64 bytes from 64.125.29.98: icmp_seq=1 ttl=54 time=19.8 ms 64 bytes from 64.125.29.98: icmp_seq=2 ttl=54 time=19.8 ms 64 bytes from 64.125.29.98: icmp_seq=3 ttl=54 time=20.0 ms 64 bytes from 64.125.29.98: icmp_seq=4 ttl=54 time=20.4 ms --- 64.125.29.98 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3001ms rtt min/avg/max/mdev = 19.861/20.062/20.432/0.290 ms
у домена указать NS'ы на самого себя, при этом указать явно IP адрес(а) NS'ов вместе с их именами
размер полигона это уже, разумеется, на Вашей совести. я только на направление намекнул.
насчет 1024x768 - ВМ накладывается на участок изображения (в большинстве случаев), потому область обхода будет меньше (равная размеру ВМ + процентов 5 вокруг, плюс если ВМ без альфаканалов и полостей, то достаточно обхода только вокруг заполняемой области), но конечноже не каждый пиксель в области проверять.
ТС, попробуйте вариант с тенями, если подойдет - то сэкономит вам и личное время и процессорное
не совсем вариант, описанный в задаче, но в некоторых проектах вместо того, чтоб вот так высчитывать яркость в зоне было принято решение просто накладывать png с альфаканалом, по краям которой были тени..на светлых участках вотермарк тенью больше проявлялся, на темных - основные контуры. но это если ВМ приемлет такой вид.. в ином случае вам сюда и в цикле пройтись по изображению попиксельно.
вполне нормально, вы ведь берете железо в аренду, а не покупаете.