Сервер
import java.net.*;
import java.io.*;
import java.util.*;
import javax.net.ssl.*;
import javax.net.*;
class Test{
public static void main(String[] args){
try{
SSLContext context = SSLContext.getInstance("TLSv1.2");
context.init(null,null,null);
SSLServerSocketFactory serverSocketFactory = context.getServerSocketFactory();
SSLServerSocket server = (SSLServerSocket)serverSocketFactory.createServerSocket(1024);
server.setEnabledCipherSuites(server.getSupportedCipherSuites());
SSLSocket socket = (SSLSocket)server.accept();
DataInputStream in = new DataInputStream(socket.getInputStream());
DataOutputStream out = new DataOutputStream(socket.getOutputStream());
System.out.println(in.readInt());
}catch(Exception e){e.printStackTrace();}
}
}
Клиент
import java.net.*;
import java.io.*;
import java.util.*;
import javax.net.ssl.*;
import javax.net.*;
class Test2{
public static void main(String[] args){
try{
SSLContext context = SSLContext.getInstance("TLSv1.2");
context.init(null,null,null);
SSLSocketFactory socketFactory = context.getSocketFactory();
SSLSocket socket = (SSLSocket)socketFactory.createSocket("localhost", 1024);
socket.setEnabledCipherSuites(socket.getSupportedCipherSuites());
DataInputStream in = new DataInputStream(socket.getInputStream());
DataOutputStream out = new DataOutputStream(socket.getOutputStream());
out.writeInt(1337);
}catch(Exception e){e.printStackTrace();}
}
}
server.setEnabledCipherSuites (server.getSupportedCipherSuites ()); socket.setEnabledCipherSuites (socket.getSupportedCipherSuites ()); [/ д2]
Обновление
, В то время как то, что я пишу ниже, верно как общий ответ об общих библиотеках, я думаю, что самая частая причина этих видов сообщения состоит в том, потому что Вы установили пакет, но не установили "-dev" версию того пакета.
ну, это не лежит - нет никакого libpthread_rt.so.1
в том списке. Вероятно, необходимо реконфигурировать и восстановить его так, чтобы это зависело от библиотеки, Вы имеете или устанавливаете то, что обеспечивает libpthread_rt.so.1
.
Обычно числа после .so являются номерами версий, и Вы будете часто находить, что они - символьные ссылки друг на друга, поэтому если у Вас будет версия 1.1 libfoo.so, то у Вас будут реальный файл libfoo.so.1.0, и символьные ссылки foo.so и нечто so.1, указывающее на libfoo.so.1.0. И если Вы установите версию 1.1, не удаляя другую, то у Вас будет libfoo.so.1.1, и libfoo.so.1 и libfoo.so теперь укажут на новый, но любой код, который требует, чтобы точная версия могла использовать libfoo.so.1.0 файл. Код, который просто полагается на версию 1 API, но не заботится, ли это 1.0 или 1.1, укажет libfoo.so.1. Как orip, на который указывают в комментариях, это объяснено хорошо в http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html .
В Вашем случае, Вы могли бы сходить с рук symlinking libpthread_rt.so.1
к libpthread_rt.so
. Никакие гарантии, что это не взломает Ваш код и съест Ваши телевизионные ужины, все же.
Ссылочная страница linux.org объясняет механику, но не объясняет ни одной мотивации позади нее :-(
Для этого, видит Компоновщик Sun и Руководство Библиотек
, Кроме того, отмечает, что "внешнее управление версиями" является в основном устаревшим на Linux, потому что управление версиями символа (расширение GNU) позволяет Вам иметь несколько несовместимых версий той же функции для присутствования в единственной библиотеке. Это расширение позволило glibc иметь ту же внешнюю версию: libc.so.6
в течение прошлых 10 лет.
похожая проблема найдена здесь: https://bugzilla.redhat.com/show_bug.cgi?id=1456202 Я пробовал упомянутое решение, и оно действительно работает.
Решения в предыдущих вопросах могут работать. Но я думаю, что это простой способ исправить это. Попробуйте переустановить пакет libwbclient
в fedora:
dnf reinstall libwbclient