Splitting a full-duplex socket

[cyberco]

I have a Server that supports full-duplex sockets (read and write
simultaneously), but a client that can't. So what I want to do is
create a proxy that talks full-duplex to the server, but over 2
seperate sockets to the client. What is the best way to do this?
Thanks,
cyberco

 

[Gordon Beaton]

I have a Server that supports full-duplex sockets (read and write
simultaneously), but a client that can't. So what I want to do is
create a proxy that talks full-duplex to the server, but over 2
seperate sockets to the client. What is the best way to do this?

I'm having trouble understanding the real problem here. TCP sockets
are full duplex at *both* ends.

There are os-specific mechanisms for duplicating a file descriptor
that you could use to separate reader and writer processes, but you
can achieve the same thing by using two Threads in your java
application.

If your client can use two separate Sockets to communicate in each of
two directions, why can't it use a single Socket to do the same?

Maybe you need to be more specific: what makes the client unable to
support full duplex sockets? Why can't you do in the client
application what you intend to do in the proxy, but without the extra
sockets?

/gordon

 

[Steve Horsley]

I have a Server that supports full-duplex sockets (read and write
simultaneously), but a client that can't. So what I want to do is
create a proxy that talks full-duplex to the server, but over 2
seperate sockets to the client. What is the best way to do this?
Thanks,
cyberco

Can you explain the problem a bit more? What is wrong with the
client, and how would 2 separate connections help?

Steve

 

[cyberco]

Hi Steve and Gordon,

Sorry for not being more specific. A full-duplex socket means that you
can simultaneously read and write over the socket. In my case the
client is a mobile phone running J2ME and not all implementations of
the J2ME Virtual Machine (JVM) support full-duplex sockets. For
instance the Nokia 6600 does while the SonyEricsson P900 doesn't. This
is a 'feature' not well documented by phone manufacturers which can
lead to a lot of problems. In my case I'm porting a J2SE application to
J2ME that relies on full-duplex sockets. To make it work on a
SonyEricsson P900 I have change the code to use seperate sockets for
reading and writing to the server. Unfortunately the serverside
application does not support seperate sockets for reading and writing,
so I'm building a proxy that talks to my phoneclient using 2 sockets
and to the server using one socket. In other words the proxy splits a
full-duplex socket. My question is what the easiest (and best) way is
to do this.

Thanks in advance for your time and effort.
Cyberco

 

[ByteCoder]

Hi Steve and Gordon,

Sorry for not being more specific. A full-duplex socket means that you
can simultaneously read and write over the socket. In my case the
client is a mobile phone running J2ME and not all implementations of
the J2ME Virtual Machine (JVM) support full-duplex sockets. For
instance the Nokia 6600 does while the SonyEricsson P900 doesn't. This
is a 'feature' not well documented by phone manufacturers which can
lead to a lot of problems. In my case I'm porting a J2SE application to
J2ME that relies on full-duplex sockets. To make it work on a
SonyEricsson P900 I have change the code to use seperate sockets for
reading and writing to the server. Unfortunately the serverside
application does not support seperate sockets for reading and writing,
so I'm building a proxy that talks to my phoneclient using 2 sockets
and to the server using one socket. In other words the proxy splits a
full-duplex socket. My question is what the easiest (and best) way is
to do this.

Just a guess, but is it possible to run a non-blocking serversocket on
the server and set it te readable and writeable. That way the input and
output socket (if possible?) on the phone could connect to that NIO
serversocket?

 

[John C. Bollinger]

Hi Steve and Gordon,

Sorry for not being more specific. A full-duplex socket means that you
can simultaneously read and write over the socket. In my case the
client is a mobile phone running J2ME and not all implementations of
the J2ME Virtual Machine (JVM) support full-duplex sockets. For
instance the Nokia 6600 does while the SonyEricsson P900 doesn't. This
is a 'feature' not well documented by phone manufacturers which can
lead to a lot of problems. In my case I'm porting a J2SE application to
J2ME that relies on full-duplex sockets. To make it work on a
SonyEricsson P900 I have change the code to use seperate sockets for
reading and writing to the server. Unfortunately the serverside
application does not support seperate sockets for reading and writing,
so I'm building a proxy that talks to my phoneclient using 2 sockets
and to the server using one socket. In other words the proxy splits a
full-duplex socket. My question is what the easiest (and best) way is
to do this.

Are you actually telling us that some of the phones in question support
simultaneous (in some sense) reading and writing on different sockets,
but not on the same one? That sounds awfully strange. Before you go to
much effort, you should make certain that your proposed solution will
actually work.

My bet would be that this is a hardware / OS issue, not a J2ME issue.
Some phones may have radios or electronics that cannot simultaneously
send and receive, for instance. That would mean that you cannot assume
full-duplex communication, period.

If you go ahead:
Does J2ME have ServerSockets? I'm guessing not. In that case, the J2ME
side must make two separate connections to the proxy, and somehow tell
the proxy which is the reading side and which the writing side, and
possibly what server to connect to (but that last could be implicit in
the choice of proxy). The proxy connects to the server, then commences
forwarding both sides of the conversation. It would probably be easiest
to code it in the form of one thread for forwarding each direction, but
there may be advantages to coding for selectable I/O within a single
thread in the proxy.


John Bollinger
(e-mail address removed)

 

[Esmond Pitt]

Just a guess, but is it possible to run a non-blocking serversocket on
the server and set it te readable and writeable.

This is not only impossible but meaningless.

 

[xarax]

This is not only impossible but meaningless.

A server socket does not read or write. It listens
for a connection request, then an accept() will
create a new socket for reading and writing. However,
the server socket can be non-blocking and selected
via select() when a connection request is pending.
The Java way of doing a select() is with the SelectionKey
thing.

 

[ByteCoder]

This is not only impossible but meaningless.

Good thing I bought Java Network Programming then.
Still have a lot to read.

 

[Filip Larsen]

John C. Bollinger wrote

Are you actually telling us that some of the phones in question support
simultaneous (in some sense) reading and writing on different sockets,
but not on the same one? That sounds awfully strange. Before you go to
much effort, you should make certain that your proposed solution will
actually work.

My bet would be that this is a hardware / OS issue, not a J2ME issue.
Some phones may have radios or electronics that cannot simultaneously
send and receive, for instance. That would mean that you cannot assume
full-duplex communication, period.

All modern over-the-air digital phones that I know of switch between
sending and receiving so fast that you effectively get a full-duplex
voice and data packet connection.

I am not familiar with the phone the OP claims have half-duplex data,
but if the claim is true then my guess would be the opposite of yours,
namely that it is a limitation in the J2ME implementation for that
particular series. For instance, a device adhering to the MIDP 1.0
specification is, as far as I know, only required to support HTTP and
datagram connectors and with only those you do not have direct access to
a TPC-like connector.


Regards,

 

[Filip Larsen]

I wrote

For instance, a device adhering to the MIDP 1.0
specification is, as far as I know, only required to support HTTP and
datagram connectors and with only those you do not have direct access to
a TPC-like connector.

That should of course be "... TCP-like connector".


Regards,

 

[cyberco]

I'm certain that some phones don't support full-duplex sockets while
others do. I'm not 100% sure whether the former do support
simultaneously writing and reading over seperate sockets. That is
something that is hard to find out from the specs. That's why I'm going
to implement it and see if it works.

J2ME does support ServerSockets.

Besides the discussion whether phones support simultaneous socket
communication I'm still interested in ideas about how to 'split' a
full-duplex socket into seperate read and write sockets.
Thanks for your help,
Cyberco

 

[cyberco]

Yes, sockets are either at both ends full-duplex or not full duplex.
That's right, and that's my problem. The server application requires a
full-duplex connection to the client, but the client doesn't support
full-duplex sockets. I have no way of changing the serverside
application so a proxy is the only solution. Question remains what the
best way is to 'split' a full-duplex socket and forward/return the
communication over 2 seperate sockets....

 

[Filip Larsen]

Question remains what the
best way is to 'split' a full-duplex socket and forward/return the
communication over 2 seperate sockets....

It depends strongly on which API is available on the device. For
instance, if you only have access to HttpConnection you will have to
simulate a full-duplex stream with those, which probably could be done
in a number of ways each with its own set of pro's and con's. Of the top
of my head here is some ideas that might (or might not) work along with
a custom proxy made to fit:

- make two HttpConnection, one to provide the output stream (never
ending request) and another to provide the input stream (never ending
reply). This do rely on the platform supporting infinite request and
replies.

- make a new HttpConnection with regular interval where you send and
receive data. The trigger for making a new poll can be based on time,
data ready to be send, or data ready to be received. In the last case,
the reply needs to be left unclosed so that the proxy can signal that it
has data.

- a combination of the two, like a new HttpConnection for each lumb of
data ready to send, but one never ending HttpConnection to receive.

In the J2SE world I have seen most of these combinations in use.


Regards,

 

[cyberco]

Thanks, Filip. I'm specifically talking about J2ME (MIDP2.0) devices,
which DO support sockets (at least the majority of them), so there's no
need to revert to HttpConnection. The problem is not on the client side
but on the proxy side...

Cheers,
cyberco

 

[cyberco]

Still no solution.... Anybody any tips?
cheers,
cyberco

 

[Filip Larsen]

Still no solution.... Anybody any tips?

If you didn't get my post with suggestions please say so and I will
repost it.


Regards,

 

[Filip Larsen]

Still no solution.... Anybody any tips?

And I said

If you didn't get my post with suggestions please say so and I will
repost it.

Sorry, didn't see your reply to the post I mention above.

I understand you have now think the problem is on the proxy side and not
on the client side? This does not makes sense to me, since you said
earlier that you want to use a proxy because the sockets on the client
did not work in full-duplex. Perhaps you could clarify which setup you
know that work and which you know that dont work.


Regards,

 

[Andrew Thompson]

Sorry, didn't see your reply to the post I mention above.

A misunderstanding which could be avoided in future by the OP not
trimming *everything* from previous posts, but posting in the style
used by Filip and myself, 'in-line posting with trimming'.

Note that the 'trimming' refers to trimming any text from earlier
messages that is no longer needed in order to give the response a
context, as opposed to trimming *all* of the previous text.

 

[Sudsy]

Still no solution.... Anybody any tips?
cheers,
cyberco

Incomplete problem description could be the difficulty. Some of what
you've posted makes no sense. A Berkeley socket is, by definition,
bidirectional. If you're using a platform which doesn't implement the
basic (expected) functionality then you'd be better served going back
to the provider.
Perhaps the lack of response is due to incomprehensibility of the
stated problem. Have you ever read the Comer books? Do you know how
TCP/IP works? I'm not trying to offend your sensibilities here, just
attempting to clarify the level of understanding.
It might be that the solution is simple and that your attempts to
"fix" the problem by using questionable mechanisms and proxies is
actually causing you grief.
As usual, YMMV

ps. Ship me the client and I'll make it work!... ;-)