简体   繁体   中英

Standard of communication between server and client

I have questions regarding the way server and client define the standard of communication between them. For reference I am using Java and the code quoted here .

  1. The client needs the server's IP to connect to it. If the server uses the method InetAddress.getLocalHost().getHostAddress() , the IP address that will be returned will be local: useful if the client is on the same machine as the server, less so otherwise. How can I get the server IP that the client needs? Is it possible to acquire this information without using external services or sites that ping your server and return your public IP?
  2. Suppose I, the client, have established Socket communication with the server. Now I need to open the input and output stream, which must be of a kind compatible with the stream on the server side. How can I know in advance the correct kind? For an example, let's consider the case of time.nist.gov , port 13. I expect the output of a communication to this server to be a String encapsulating the current date. Does the server transmit said String through an ObjectOutputStream , or maybe an OutputStreamWriter ? How can I know?

The client needs the server's IP to connect to it... How can I get the server IP that the client needs? Is it possible to acquire this information without using external services or sites that ping your server and return your public IP?

The client either must know either the IP address or the host name of the server. If the host name is known, the IP address can be figured out on the client's side using InetAddress.getByName( "java.sun.com" ) , using java.sun.com as an example.

I need to open the input and output stream, which must be of a kind compatible with the stream on the server side. How can I know in advance the correct kind?

Since the messaging varies from protocol to protocol, the client has to know what the server supports and write its input and output streams accordingly. Usually, client-server systems communicate in bytes-based input and output. That is, plain bytes data will be exchanged between the client and the server. They then convert these bytes from/to characters where needed based on the agreed upon character encoding, like UTF-8.

Does the server transmit said String through an ObjectOutputStream, or maybe an OutputStreamWriter?

Here is where the idea of a protocol needs understanding. You may already know, however, I am writing it just to explain clearly. A protocol is an agreement or contract of the messaging style - how many bytes to send, when to send, how to encode, etc. Eg, in SMTP the client has to first say HELO or EHLO, upon receiving which the server returns a specific response. The client must know what to expect at this stage and how to move further based on the protocol.

Usage of ObjectInputStream and ObjectOutputStream

Now, ObjectInputStream and ObjectOutputStream is a Java-specific wrapper over IO streams to read and write byte buffers in the "shape" of Java objects. That is, these classes serve only Java-object-specific purposes. This is fine if it known that the server is communicate using serialized/deserialized Java objects. However, the server the client is connecting may not be using Java at all! Or even if it is, it may be communicating in pure characters or bytes and not in Java objects.

I am not sure what protocol time.nist.gov:13 is using. You will need to understand that and code your client accordingly. However, since you have mentioned that it returns a string:

  1. Simply use socket.getInputStream() on the client, without wrapping it with ObjectInputStream
  2. Read the bytes from this stream till EOF
  3. Convert these bytes into a String considering the character encoding published by the site, say, UTF-8. new String( bytes, StandardCharsets.UTF_8 ) .

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM