RFC: Design for simultaneous socket connections

[blackbird]

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...???

[kjkrum]

The answer probably depends on the protocol being used for the transfer.

[blackbird]

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.

[kjkrum]

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]

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.

[kjkrum]

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?

[blackbird]

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.