Results 1 to 7 of 7
Like Tree3Likes
  • 1 Post By kjkrum
  • 2 Post By kjkrum

Thread: RFC: Design for simultaneous socket connections

  1. #1
    blackbird is offline Senior Member
    Join Date
    Jul 2011
    Posts
    100
    Rep Power
    0

    Default RFC: Design for simultaneous socket connections

    I've been tasked with creating a utility that will pass the contents of file1 to the server on port 12345 and simultaenously pass the contents of file2 to the same server on port 12346.

    Should I create two threads for this - one for listening to the server's response from the message sent to port 12345, and the second for listening to the server's response from the message sent to port 12346, or should I create FOUR threads (two for sending, two for listening) or perhaps three (using the main thread for one sending operation) or...???

  2. #2
    kjkrum's Avatar
    kjkrum is offline Senior Member
    Join Date
    Apr 2011
    Location
    Tucson, AZ
    Posts
    1,060
    Rep Power
    6

    Default

    The answer probably depends on the protocol being used for the transfer.
    Get in the habit of using standard Java naming conventions!

  3. #3
    blackbird is offline Senior Member
    Join Date
    Jul 2011
    Posts
    100
    Rep Power
    0

    Default

    Quote Originally Posted by kjkrum View Post
    The answer probably depends on the protocol being used for the transfer.
    TCP/IP; I'm wondering if I can use Timers to read lines from the files and put them into the output stream.

  4. #4
    kjkrum's Avatar
    kjkrum is offline Senior Member
    Join Date
    Apr 2011
    Location
    Tucson, AZ
    Posts
    1,060
    Rep Power
    6

    Default

    TCP/IP is not an application protocol; it's a transport layer. If you open a socket in Java, sure, whatever you write to or read from that socket is carried by TCP/IP. But that's completely transparent to your application. You don't (and AFAIK, can't) deal with TCP/IP directly in Java without resorting to a third-party library.

    What I mean is, what is the protocol on top of TCP/IP that you're using to transfer files? HTTP? FTP? If you're just writing bytes to a raw socket, you're not going to get any response at all unless you code one. And then you've coded a custom protocol. If that's your plan, can you describe it?
    blackbird likes this.
    Get in the habit of using standard Java naming conventions!

  5. #5
    blackbird is offline Senior Member
    Join Date
    Jul 2011
    Posts
    100
    Rep Power
    0

    Default

    Quote Originally Posted by kjkrum View Post
    TCP/IP is not an application protocol; it's a transport layer. If you open a socket in Java, sure, whatever you write to or read from that socket is carried by TCP/IP. But that's completely transparent to your application. You don't (and AFAIK, can't) deal with TCP/IP directly in Java without resorting to a third-party library.

    What I mean is, what is the protocol on top of TCP/IP that you're using to transfer files? HTTP? FTP? If you're just writing bytes to a raw socket, you're not going to get any response at all unless you code one. And then you've coded a custom protocol. If that's your plan, can you describe it?
    I wouldn't call it creating a custom protocol; I've simply created the simplest possible proof-of-concept passing of messages back and forth between two computers using sockets, and will now build on it/extend it. It's basically the TCPEchoServer and TCPEchoClientGUI code from the Java TCP/IP book.

  6. #6
    kjkrum's Avatar
    kjkrum is offline Senior Member
    Join Date
    Apr 2011
    Location
    Tucson, AZ
    Posts
    1,060
    Rep Power
    6

    Default

    Ah, just an echo server. Okay. Then I guess it depends on how you want your program to behave. For maximum transfer speed, I'd have two threads per file transfer on the client side: one writing lines, the other reading and verifying the echo. For more simplicity (which might not have much impact on transfer speed at all) just use one thread per transfer, alternately writing lines and reading the echo.

    For a more complex "real world" protocol, the decision might come down to something like: does the response to each message you send make a difference to the next? If so, you might only use one thread per connection, since the sending thread has to wait for a response to decide what to do next. On the other hand, if all you want to do with the responses is log them and maybe occasionally interrupt or change the behavior of the sender, the two-thread approach might be better.

    Any reason you're using two different ports on the server?
    Norm and blackbird like this.
    Get in the habit of using standard Java naming conventions!

  7. #7
    blackbird is offline Senior Member
    Join Date
    Jul 2011
    Posts
    100
    Rep Power
    0

    Default

    Quote Originally Posted by kjkrum View Post
    Any reason you're using two different ports on the server?
    Yes, that's what I was told to do - send the contents of one file, one line at a time, to port 4211, and the contents of the other file (one line at a time) to port 4212.

    BTW, I agree points #7 and #8 are kind of dumb; #8 I just find unncessary, but #7 I think is counterproductive/intuitive.

Similar Threads

  1. Are LAN only connections possible?
    By paul pasciak in forum Networking
    Replies: 1
    Last Post: 10-01-2010, 02:55 AM
  2. Replies: 1
    Last Post: 07-02-2010, 01:18 PM
  3. design & generics for socket server
    By gilme in forum New To Java
    Replies: 1
    Last Post: 06-18-2010, 04:24 AM
  4. Replies: 24
    Last Post: 12-03-2009, 10:58 PM
  5. Doubt in simultaneous 'implementation' and 'extension'
    By ajaygargnsit in forum New To Java
    Replies: 2
    Last Post: 12-20-2007, 09:33 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •