File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Sockets and Internet Protocols and the fly likes two sockets communication in multi-thread Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Sockets and Internet Protocols
Bookmark "two sockets communication in multi-thread" Watch "two sockets communication in multi-thread" New topic

two sockets communication in multi-thread

Roy Huang
Ranch Hand

Joined: Nov 21, 2001
Posts: 104
Hi, happy new year!
I have problem with implementing two sockets communication in my client applet: one socket will send the audio stream to server A, after that another will receive the audio stream from server B.
I would like to use two threads for the socket communications. Who has such experience, could U offer me some basic codes about:
1. send and receive the ByteArrayInputStream through sockets (for the efficiency and fast way)
2. multithread control;
That would be very helpful, thanks.
Wish Javaranch guys good luck in 2002!

SCJP 1.4/SCBCD/SCWCD<br />MCSE<br />IBM professional XML Developer<br />SAP certified Development Consultant (NetWeaver portal and Web JavaApplication)
Michael Ernest
High Plains Drifter

Joined: Oct 25, 2000
Posts: 7292

Hi Roy -
Ok, so you've got machine C which is receiving audio from machine B and sending audio to machine A.
Machine C operates in this context similar to what we call an Adapter in Design Pattern language. That is, the program on machine C acts like an "interpreter" between the interfaces of two other programs that can't or don't talk directly to each other.
If you think of machine B as a data producer, and machine A as a data consumer, the threading model becomes real clear. Machine C's job is to block incoming data when it's buffer is full, and block outgoing data when it's buffer is empty. Outside of those conditions, allowing each side to push or pull data at their discretion would be the most effective use of threading in the middleware.
The format by which you send the data will be bytes no matter what you do. It's just a question of who does the byte-making. Using ByteArrayInputStream is efficient for sending and receiving, but you'll reassemble those bytes into their original data format, and that will cost something. It's the shape of the data itself that really determines the most effective method of transporting it.
Michael Ernest, co-author of: The Complete Java 2 Certification Study Guide

Make visible what, without you, might perhaps never have been seen.
- Robert Bresson
Roy Huang
Ranch Hand

Joined: Nov 21, 2001
Posts: 104
Hi, Michael,
thanks for Ur tips.
--specially get it on the first day of 2002 !
But I think there're some misunderstanding here.
The machine C (what I am using is a applet) will send the audio stream(which is created by the user's microphone input) to Machine A, after a series of handling work, the result(another audio stream) will from machine B sent back to machine C(the applet).

and so these are complete two different audio streams, if Machine C get the input from the microphone, they will prepare to send it, and after it, Machine C is waiting for the answer from machine B. then according the feedback, the user will speak further through mic.
--I don't think it is still the Pipe structure, since machine C will not take the 'interpreter' role.

furthermore, how can I solve the problem for the security?
--I suppose I get the applet from machine A, so the machine A trusts Machine C's applet for accepting its stream, and in the machine C, (if I allow the local machine accept any java applets to access the local resource through java.policy file), will any security problem still occur when it needs to get the stream from Machine B through socket communication?
--since this applet is not getting directly from machine B?
Michael, do U think it is enough to prevent the security problem?

I agree. Here's the link:
subject: two sockets communication in multi-thread
It's not a secret anymore!