🚀 go-pugleaf

The implementations are hidden so that the JVM providers (and perhaps
third-party library providers) can implement the sockets in the best manner
possible for the underlying environment.  Other categories of API in which
this occurs are file I/O, screen management, and event (keyboard and mouse)
management.

As for distinguishing between clients, the TCP/IP protocol takes care of
that.  It ensures that the incoming data is routed to the correct socket
based on the source IP address and port; what you see in Java is that all
requests from a given client will come through the same input stream.  Java
doesn't need to do anything other than map the underlying OS API into the
Java API.

-- 
Check out our latest white papers at
http://www.datadevelopment.com/papers/index.html

BladeNET Scores With Borland Enterprise Tools
Team Development with JBuilder and Borland Enterprise Server

Dolphin Data Development Ltd.
http://www.datadevelopment.com/

"Alan Shiers" <ashiers@hfx.eastlink.ca> wrote in message
news:3EE34D95.E0767B34@hfx.eastlink.ca...
> Hi there,
>
> It maybe that Sun has hidden the implementation from us when they made
> the java.io.Socket and java.io.ServerSocket classes, but out of
> curiosity, I was wondering how a socket is able to distinguish incoming
> data as belonging to a specific ongoing process?
>
> In other words,  in a client/server application, it is possible that you
> could have two or more clients logged on to the server application
> simultaneously. Naturally, it is possible to assume that, for each
> client logged on, each would be sending and receiving different pieces
> of data all at the same time.  This being the case, is the Socket or
> ServerSocket class able to distinguish the fact that certain incoming
> data is intended as a request from Client2 and not from Client3? After
> all, they all obtain their InputStreams and OutputStreams in the same
> manner by calling the respective methods of the Socket or ServerSocket
> classes [getInputStream() or getOutputStream()].
>
> Alan

Kevin Dean wrote:
> 
> As for distinguishing between clients, the TCP/IP protocol takes care of
> that.  It ensures that the incoming data is routed to the correct socket
> based on the source IP address and port; what you see in Java is that all
> requests from a given client will come through the same input stream.  Java
> doesn't need to do anything other than map the underlying OS API into the
> Java API.


Ok, so what if you have two separate sockets set to the same Port
Number? Let's also say, that you have different InputStream and
OutputStream type classes connected to each Socket. For instance, you're
using DataInputStream and DataOutputStream on Socket1 and
BufferedInputStream and BufferedOutputStream on Socket2.

Since we're trying to send/receive different types of data through these
sockets and they both are set to the same Port Number, is there any
chance that the incoming data can get mixed up, thereby causing
Exceptions? If there is this possibility, then perhaps it's better to
have each socket set at a different Port Number to ensure data transfer
integrity?

Regards,

Alan

On 6/9/2003 at 12:11:06 PM, Alan Shiers wrote:

> Ok, so what if you have two separate sockets set to the same Port
> Number?

What do you mean by "set to the same Port Number"?  Are you talking
about ServerSockets or client Sockets?  Perhaps if you posted some
code, it would be a little more clear what you are doing.

-- 
Regards,

John McGrath  [TeamB]

 
> What do you mean by "set to the same Port Number"?  Are you talking
> about ServerSockets or client Sockets?  Perhaps if you posted some
> code, it would be a little more clear what you are doing.

Yes, I'm referring to ServerSockets.
Conceptually speaking this is all I'm trying to accomplish:

I want one primary ServerSocket open with DataInputStream and
DataOutputStream classes connected to it, and remains listening to the
Port specified in the application, and for the duration that any Client
may be connected. Then, a separate secondary ServerSocket, which only
gets activated, on the fly, with BufferedInputStream and
BufferedOutputStream classes connected to it. 

The idea being that, the primary ServerSocket is used only to send
integer values (representing Constants defined in the application) back
and forth between the server app and the Client app. And the secondary
ServerSocket is used only to upload/download files at the byte level
only.

So, the question remains, will there be a conflict of data transfer if
both ServerSockets are set to the same IP address and on the same Port
Number?  Is it better to at least have each ServerSocket set to
different Port Numbers to prevent conflict of data transfer?

Alan

A server socket is one that listens on a specified port.  When a client
makes a connection on that port, it starts a unique conversation between it
and the server.  At that point, you can send whatever you like up and down
the pipe as long as the client and the server agree on the data format.
There will never be any conflict between one client and another.  There is
nothing preventing you from changing the data format to a byte stream for
raw binary data and then switching it back again.

The problem you will have in spawning a second server socket is this:
suppose both client 1 and client 2 are instructed to make a connection on
that socket.  Client 1 is told first, 100ms before client 2.  However,
client 2 is faster and establishes the connection to the second server
socket.  Your server thinks it's talking to client 1 because that's the one
that was told to initiate contact first.

Your best bet is to use a single dedicated connection for your session.

-- 
Check out our latest white papers at
http://www.datadevelopment.com/papers/index.html

BladeNET Scores With Borland Enterprise Tools
Team Development with JBuilder and Borland Enterprise Server

Dolphin Data Development Ltd.
http://www.datadevelopment.com/

"Alan Shiers" <ashiers@hfx.eastlink.ca> wrote in message
news:3EEA1B0B.F96AB3D@hfx.eastlink.ca...
>
> > What do you mean by "set to the same Port Number"?  Are you talking
> > about ServerSockets or client Sockets?  Perhaps if you posted some
> > code, it would be a little more clear what you are doing.
>
> Yes, I'm referring to ServerSockets.
> Conceptually speaking this is all I'm trying to accomplish:
>
> I want one primary ServerSocket open with DataInputStream and
> DataOutputStream classes connected to it, and remains listening to the
> Port specified in the application, and for the duration that any Client
> may be connected. Then, a separate secondary ServerSocket, which only
> gets activated, on the fly, with BufferedInputStream and
> BufferedOutputStream classes connected to it.
>
> The idea being that, the primary ServerSocket is used only to send
> integer values (representing Constants defined in the application) back
> and forth between the server app and the Client app. And the secondary
> ServerSocket is used only to upload/download files at the byte level
> only.
>
> So, the question remains, will there be a conflict of data transfer if
> both ServerSockets are set to the same IP address and on the same Port
> Number?  Is it better to at least have each ServerSocket set to
> different Port Numbers to prevent conflict of data transfer?
>
> Alan

Kevin Dean wrote:
> There is nothing preventing you from changing the data format to a byte >stream for raw binary data and then switching it back again.
> 

You know, initially I tried this approach but began to have problems. 
Originally I had only one ServerSocket and using only DataInputStream
and DataOutputStream classes on the connection.  As we know, you use the
getInputStream() and getOutputStream() methods of the ServerSocket
object to connect with the stream classes just mentioned.  However, when
I called a method that is designed specifically to download a file
whereby I switched to BufferedInputSteam and used the getInputSteam()
method of the ServerSocket object to connect, I then seemed to have lost
my connection with the DataInputStream and DataOutputStream objects
because when I began to use them, after returning from the download
method, I started getting Exceptions. I thought that calling
getInputStream() on the ServerSocket object in the download method was
disconnecting the DataInputStream object, and I can't have that!  When
returning from the download method should I have called the
getInputStream() method again for the DataInputStream object to
re-establish the connection?

Alan