Всем привет! Каким образом возможно в php получать сериализованные объекты из java через сокет в php? На java есть многопоточный сервер, который должен получать из php через сокет некий объект обрабатывать его и отправлять обратно. пробовал сделать отправку json Код (Text): {"key":"val", "key2":"val2"} да, отправляет, да получаю на стороне java, через стороннюю библиотеку (json.org) разбираю его, делаю манипуляции, собираю опять в json с помощью той же библиотеки пишу в сокет, и на стороне php socket_read - пустой (читается ведь им в данном случае?). Хотя c сервера в сокет записалось. тестировал как java сервер ->java клиент все арбайтен. а когда начинаю писать в сокет и клиент на php то неарбайтен. PHP: $address ='localhost';//Адрес работы сервера $port =1985;//Порт работы сервера (лучше какой-нибудь редкоиспользуемый) if(($socket = socket_create(AF_INET, SOCK_STREAM, SOL_TCP))<0){ //AF_INET - семейство протоколов //SOCK_STREAM - тип сокета //SOL_TCP - протокол echo "Ошибка создания сокета"; } else{ echo "Сокет создан\n"; } $result = socket_connect($socket, $address, $port); if($result ===false){ echo "Ошибка при подключении к сокету"; }else{ echo "Подключение к сокету прошло успешно\n"; } $out = socket_read($socket,MAXLINE);//Читаем сообщение от сервера Подскажите как на стороне php читать тот же json из сокета?
@Ganzal Ты волшебник =) Спасибо, спасла эта функция socket_recv! все заработало.... (был бы сильно признателен если бы ты мне в кратце сказал почему оно заработало) Может подскажешь тогда еще момент по отправке, как лучше отправлять json на мой сервер? json будет около 300 ключей иметь, значения в основном циферки. И правильно ли я понимаю что сериализованный объект php (с помощью функции serialize()) в java я не разгребу из за разного механизма сериализации?
емнип, рид это тот же ресив, но с какими-то непрозрачными флагами. я много лет назад тоже изрядно потрахался с этой парой функций))) да обычными socket_write() вполне работает. проверено на личной связке пхп-клиент + джава-сервер. да, сериализацию разные языки могут выполнять по-разному ибо это для их нужда. а вот json это уже по сути транспортная кодировка имеющая определенный стандарт и все япы должны на выходе выдавать одинаковую закодированную последовательность при равных по логике входных данных.
" я много лет назад тоже изрядно потрахался с этой парой функций)))" Забыть как страшный сон хочется уже сейчас. А переубедить человека на то что бы веб морда была на джаве написана, ни в какую. И уже мысленно жду звонка, когда будет "работать" потоков 500 одновременно с десятком запросов в секунду.
Не думаю, что какая-то проблема с производительностью будет. Даже на слабеньком офисном компе может потянуть. Была у меня необходимость с миллионом строк работать. Бинарки в 16-20 байт. Написал сервер на пхп, сделал запрос, подождал 10 секунд, получил ответ. Остался недоволен ибо таких запросов надо делать много и регулярно, а времени столько нет. Плюс отожрал тогда пых что-то очень много памяти, что мне не очень понравилось. Решил написать на джаве. Изучил нужный минимум, написал, запустил, сделал запрос - ~0.1 сек. Круто. Вспомнил, что клиентов можно в многопоточном режиме обрабатывать: переписал немного код сервера - ~0.15 сек/запрос. За пару лет эксплуатации объем данных вырос в 8-9 раз. время выполнения - ~0.3 сек. Сделал небольшую оптимизацию: разделил на сервере один большой массив на тысячи более маленьких и сделал фильтр а-ля индекс - если тебе не нужны данные из этого банка, то ты его проходишь мимо. Результат: ~0.02 сек. Старый двухъядерник держит расчетный десяток клиентов, а больше от него ничего и не требуется. Когда будет публичная эксплуатация там и железо в конце концов будет другое))) Тут нужно оговориться, что пых был версии 5.5 и 7 еще была только в мечтах. С её кишками может и будет работать быстрее, чем на 5.5, но пока времени и желания проводить бенчмарки тупо нет. Но эту оговорку я делаю с намёком именно на производительность пхп7. А она в некоторых местах просто рвань какая. Если у тебя вся морда на пхп и тебе только три сотни логнов вызывают проблемы - надо сравнить производительность и удобство обслуживания алгоритмов написанных на пыхе и на джаве, и уже тогда решить на чем сделать остановку.