remote netcat talking to a Java app

[neuneudr]

Hi all,

is it possible to have a Java app listen on a socket (?)
and be *instantly* notified when a remote shell script
netcats something on that socket?

I have control on the exact number of bytes sent by
netcat. Say the shell script does this:

echo "something" | netcat 10.0.0.39 3423

And I've got a Java app configured to 'listen' on
socket 3423, can I be instantly notified when the
9 letters of "something" have been netcat'ed.

Imagine, out of simplicity (?) that it's always
exactly the same number of bytes that are going
to be sent by netcat and that netcat shall work
in TCP mode.

What should I do on the Java side? Which class
should I use and how can I do so that I don't need
to 'poll' the socket but be instantly notified when
something arrives on the socket? (it has to work
on Java 5).

It is maybe a dumb question but I've got no idea
as to how Java application listen on sockets and
how they're supposed to act when something comes
on the socket.

Any explanation greatly appreciated : )

 

[neuneudr]

I need to precise that the goal is not scalibility/perfs
for thousands nor hundreds of remote shell script that would
be netcatt'ing to the Java app.

There's going to be exactly *one* remote shell script doing
the netcat and the goal is to minimize the delay between
the time the netcat is issued on the remote machine by the
shell script and the time at which my Java apps can call a
callback.

Because the goal is to minimize the delay, polling is out of
question (a 100 ms delay, for example, would already be very
laggy for my needs). Typically the two machines will be on
the same network and a round-trip ping takes less than 1 ms.

I'd like to have that kind of reactivity between a netcat and
the Java app.

 

[Daniel Pitts]

Hi all,

is it possible to have a Java app listen on a socket (?)
and be *instantly* notified when a remote shell script
netcats something on that socket?

I have control on the exact number of bytes sent by
netcat. Say the shell script does this:

echo "something" | netcat 10.0.0.39 3423

And I've got a Java app configured to 'listen' on
socket 3423, can I be instantly notified when the
9 letters of "something" have been netcat'ed.

Imagine, out of simplicity (?) that it's always
exactly the same number of bytes that are going
to be sent by netcat and that netcat shall work
in TCP mode.

What should I do on the Java side? Which class
should I use and how can I do so that I don't need
to 'poll' the socket but be instantly notified when
something arrives on the socket? (it has to work
on Java 5).

It is maybe a dumb question but I've got no idea
as to how Java application listen on sockets and
how they're supposed to act when something comes
on the socket.

Any explanation greatly appreciated : )

Read the JavaDocs for ServerSocket, it should answer all your questions.

If you have trouble after that, provide an SSCCE <http://sscce.org>, so
that we may further assist you.

I believe what you are asking is technically possible, but I don't feel
like writing your program for you to explain it.

 

[neuneudr]

On Dec 11, 4:26 pm, Daniel Pitts

Read the JavaDocs for ServerSocket, it should answer all your questions.

So blocking I/O would be the way to go?

So I can simply block, in a thread, on DatagramSocket.receive()?

What would be the overhead for the other threads of having a thread
being blocking on I/O?

I believe what you are asking is technically possible, but I don't feel
like writing your program for you to explain it.

I'm not asking that... I try to understand what is at work here.

 

[markspace]

Because the goal is to minimize the delay,

The delay in Java should be exactly the same as the delay that a C
program using a native library would have listening on the same socket.
It's completely dependent on the sending system, the network itself,
and the remote OS.

I agree polling is a bad idea. There's no reason not to just block on
the socket and avoid wasting CPU resources.

In both C and Java, the method call is "accept()" iirc to receive an new
socket connection. Just do that and you'll be fine.

<http://java.sun.com/docs/books/tutorial/networking/sockets/clientServer.html>

 

[Daniel Pitts]

On Dec 11, 4:26 pm, Daniel Pitts


So blocking I/O would be the way to go?

So I can simply block, in a thread, on DatagramSocket.receive()?

What would be the overhead for the other threads of having a thread
being blocking on I/O?



I'm not asking that... I try to understand what is at work here.

And I'm asking you to try something yourself, and then come back if it
doesn't work as expected. Let us know what you've tried, and we'll be
likely to tell you why it failed and what to change.

 

[neuneudr]

On Dec 11, 9:39 pm, Daniel Pitts

And I'm asking you to try something yourself, and then come back if it
doesn't work as expected.

Which is mostly pointless when one doesn't know what to expect,
which was *precisely* why I came posting to c.l.j.p...

I came with a very precise question and your answer was
basically "RTF ServerSocket Javadoc".

I was looking for "explanation", which I stated. To grasp the
"bigger picture".

Your RTFA post didn't tell much about blocking I/O or
non-blocking I/O. It didn't tell much about non-blocking
synchronous, nor non-blocking asynchronous.

It didn't tell much about wether ServerSocket would be
a good fit to minimize latency or not.

Nor if polling would be a good way to minimize latency.

Nor if spawning a separate thread doing blocking I/O would
be a good way to proceed and likely or not to affect the
perfs of the rest etc.

I'm sorry but I don't buy neither Lew's grammar-naziness
nor your tone which I found rude in both your posts.

This is Usenet, people ask questions. If it's to answer
"go to http://java.sun.com, I'm not spending time writing
code for you" then you could even spare you the trouble
of answering my posts.

Such answers, honestly, won't be missed.

I don't give a flying f*ck about the fact that you're a
regular here or not and I honestly don't give a flying
f*ck either if all the other regulars come up to tell
"oh but I don't think it was rude".

Daniel Pitts rudely wrote:

"I believe what you are asking is technically possible,
"but I don't feel like writing your program for you to
"explain it.

Seriously, wtf!?

Killfile me, I won't miss your rudeness.

 

[Lew]

I'm sorry but I don't buy neither Lew's grammar-naziness
nor your tone which I found rude in both your posts.

<http://en.wikipedia.org/wiki/Godwin's_Law>

Boy, you really have a bug up your butt, don't you? I hadn't even posted to
this thread until you popped up with my name.

Such answers, honestly, won't be missed.

Neither will your nonsense.

I don't give a flying f*ck about the fact that you're a

OOH! You are such a gentleman!

regular here or not and I honestly don't give a flying
f*ck either if all the other regulars come up to tell
"oh but I don't think it was rude".

You are so full of nonsense.

Daniel Pitts rudely wrote:

"I believe what you are asking is technically possible,
"but I don't feel like writing your program for you to
"explain it.

Seriously, wtf!?

Seriously, all he's doing is telling you that a few minutes effort on *your*
part will make the answer clear. Your nastiness in response just tells a lot
about you.

Killfile me, I won't miss your rudeness.

There's the pot calling the kettle black. You're sure fond of the name
calling and finger-pointing and coy almost-obscenities. Why don't you just
grow up?

Too bad you will miss out on the useful advice given by Daniel and others.

 

[Arne Vajhøj]

On Dec 11, 9:39 pm, Daniel Pitts


Which is mostly pointless when one doesn't know what to expect,
which was *precisely* why I came posting to c.l.j.p...

I came with a very precise question and your answer was
basically "RTF ServerSocket Javadoc".

Which (assuming the docs does discuss the topic) is an excellent
suggestion.

I'm sorry but I don't buy neither Lew's grammar-naziness
nor your tone which I found rude in both your posts.

Since Lew did not participate in this thread there is
really not much point in dragging him into it.

This is Usenet, people ask questions. If it's to answer
"go to http://java.sun.com, I'm not spending time writing
code for you" then you could even spare you the trouble
of answering my posts.

Why?

He is giving good advice that future programmer could
take notice of.

Since it is the poster that has the problem, then it is
the posters job not the answers job to do the boring work
of providing the starting point of code.

Such answers, honestly, won't be missed.

Sure they will.

Arrogant posters of questions that are too lazy or too dum
to write code that test and/or explain the problem will
on the other hand not be missed.

Arne

 

[Knute Johnson]

Hi all,

is it possible to have a Java app listen on a socket (?)
and be *instantly* notified when a remote shell script
netcats something on that socket?

Depends on your definition of instantly but UDP is going to be faster
than making a TCP/IP connection. Will it be really fast? Yes! You
could give some indication of what you think you need in terms of speed.

I have control on the exact number of bytes sent by
netcat. Say the shell script does this:

echo "something" | netcat 10.0.0.39 3423

And I've got a Java app configured to 'listen' on
socket 3423, can I be instantly notified when the
9 letters of "something" have been netcat'ed.

Pretty darn fast.

Imagine, out of simplicity (?) that it's always
exactly the same number of bytes that are going
to be sent by netcat and that netcat shall work
in TCP mode.

OK, then it will be a little slower than UDP but the fixed length record
makes it pretty easy to know when to disconnect.

What should I do on the Java side? Which class
should I use and how can I do so that I don't need
to 'poll' the socket but be instantly notified when
something arrives on the socket? (it has to work
on Java 5).

Typically if you don't have to do a lot of connections, you can have a
thread loop through ServerSocket.accept() and then another thread to
process the connection. If you need an example, post back.

It is maybe a dumb question but I've got no idea
as to how Java application listen on sockets and
how they're supposed to act when something comes
on the socket.

Any explanation greatly appreciated : )

See above.

In terms of raw speed, UDP is going to be much faster since no
connection transaction or confirmation of data arrival is going to have
to take place as with TCP/IP. You could open a DatagramSocket and block
on a read. Then when a packet arrives you can process the data and wait
for the next packet. If the packets are all going to be small messages
or bits of data then I think it will be easier to use UDP but you have
the risk that UDP packets can be lost. That risk is pretty low on a
closed network but if you are sending these messages around the world,
the odd packet might get lost. If 100% packet arrival is not critical
then I would still suggest UDP for speed.

 

[Martin Gregorie]

Depends on your definition of instantly but UDP is going to be faster
than making a TCP/IP connection. Will it be really fast? Yes! You
could give some indication of what you think you need in terms of speed.

I agree. Start by defining the maximum acceptable delay.
Once you've defined what delay you'll accept, instrument your test setup
so you can measure the actual delay. Putting the finest grained timestamp
you can obtain in the message, sending it via netcat and comparing that
with the time after the message has been completely received by the Java
app would be a good start. If the delay is longer than is acceptable,
post the test script and Java code and we can comment about a concrete
example.

You're most unlikely to see a delay that's less than half the ping
response. Its probably unrealistic to expect a one-way TCP/IP delay that
is less than twice the ping response.

You don't say whether this message will occur many times during a run or
of it is merely a one-off. This affects response time: subsequent
messages will be quicker because address translation results, etc. are
now cached.

Be aware that the OS you're using, and hence the performance of its
command interpreter, loader and task switcher can have a significant
impact when an interaction is simply:
- open connection
- send one message
- close connection

The network topology is also significant, so make certain that your test
network is a similar as possible to the live network, especially in terms
of routers, firewalls and how address translation is handled (DNS or /etc/
hosts). For example, pinging to my local router takes 2 mS but pinging my
ISP's kit takes 28 mS

 

[EJP]

is it possible to have a Java app listen on a socket (?)
java.net.ServerSocket.

and be *instantly* notified when a remote shell script
Socket.getInputStream.read().

And I've got a Java app configured to 'listen' on
socket 3423, can I be instantly notified when the
9 letters of "something" have been netcat'ed.

You will get the data when it arrives, subject to scheduling delays and
overheads.

This is exactly the same as for any other Java networking application.

Imagine, out of simplicity (?) that it's always
exactly the same number of bytes that are going
to be sent by netcat and that netcat shall work
in TCP mode.

Makes no difference.

 

[bbiandov]

Something that simple is impossible in Java... LOL I have played with robot control UI - Java is useless. You will end up with three hundred lines of code for something that one can do in 1 line in Bash and it will still not work reliably.

I don't have an advice, sadly I am still looking for something decent myself. I will hate if the answer is dot net