Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / March 2007

Tip: Looking for answers? Try searching our database.

Challenge with simple proxy server

Thread view: 
roassaf@gmail.com - 22 Mar 2007 22:24 GMT
Hi,

I am trying to change the following code(in the link) so it will not
use threads.

http://www.skywayradio.com/tech/java/examples/SimpleProxyServer.java.html

I was told it can be done with no threads and using one socket, one
inputstream and one outputstream but I can't seem to make it work.

When I remove the use of threads I hang when I read from input stream
(in the inner whiles condition)
Anyone has an idea?

Thanks
Esmond Pitt - 23 Mar 2007 01:02 GMT
> I am trying to change the following code(in the link) so it will not
> use threads.
>
> http://www.skywayradio.com/tech/java/examples/SimpleProxyServer.java.html

Forget it.

> I was told it can be done with no threads and using one socket, one
> inputstream and one outputstream but I can't seem to make it work.

You were misinformed. This thing needs more threads, not less.

> When I remove the use of threads I hang when I read from input stream
> (in the inner whiles condition)

You will hang waiting for data, or for the peer to close the socket. If
you read the end that is waiting for data you will hang forever. This is
why you were misinformed. A single-thread strategy would only work if
you knew the application protocol and could read the correct amount of
data from the correct end first, writing it to the other end, then switch.
Christian - 23 Mar 2007 13:47 GMT
Esmond Pitt schrieb:

>> I am trying to change the following code(in the link) so it will not
>> use threads.
[quoted text clipped - 16 lines]
> you knew the application protocol and could read the correct amount of
> data from the correct end first, writing it to the other end, then switch.

I would say .. have a look at non blocking IO ...
the package java.nio    with SocketChannel  and ServerSocketChannel may
fit your needs.

Christian
roassaf@gmail.com - 23 Mar 2007 18:07 GMT
On Mar 23, 2:02 am, Esmond Pitt <esmond.p...@nospam.bigpond.com>
wrote:
> roas...@gmail.com wrote:
> > I am trying to change the following code(in the link) so it will not
[quoted text clipped - 17 lines]
> you knew the application protocol and could read the correct amount of
> data from the correct end first, writing it to the other end, then switch.

Hi,

Well I have a friend who solved it.
Stuff I forgot to mention is that the protocol is HTTP/1.1
and that the request is not pipelined and non persistent.(new socket
for each request and each request can be handeld one at a time)
Does this make any difference?
Esmond Pitt - 24 Mar 2007 04:18 GMT
> On Mar 23, 2:02 am, Esmond Pitt <esmond.p...@nospam.bigpond.com>
> wrote:
[quoted text clipped - 29 lines]
> for each request and each request can be handeld one at a time)
> Does this make any difference?

For non-persistent HTTP you have to read from the client first, writing
everything you get to the server as you go, and then reverse direction.
Close everything when you get the EOF from the server. You will have to
use a shortish read timeout so you know when to reverse. But this
strategy still adds latency up to the value of the timeout. NIO is by
far the best option here.


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.