Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > problem with sockets

Reply
Thread Tools

problem with sockets

 
 
ian@frogcottage.demon.co.uk
Guest
Posts: n/a
 
      01-04-2008
Hi
I've just started using ruby and thought I'd do some experimenting
with TCPSocket and TCPServer

I've got a small problem, in that the program I've written runs fine
on Linux, but runs with a lag on windows. By this I mean that when you
type into the client on std input in Linux, what you type is
automatically displayed.
However in windows nothing happens until you type and send something
else. Like it's caught in a buffer and needs to be flushed. I've tried
flushing the output stream as you would in Java, but nothing seems to
work
If anyone could give me some advice I would be eternally grateful.
I've searched around the net, but to no avail.

Client

require 'socket'
require 'thread'

class Client

def initialize

host = 'localhost'
port = 40000

s = TCPSocket.new(host, 40000)


t = Thread.new do

while(true)

line = s.gets

if(line == nil)
puts("Program is exiting")
break
end #of if

$stdout.flush



puts "Received: #{line}"



$stdout.flush

end #of while

s.close

end #of thread

while(true)

puts("About to run stdin")

line = $stdin.gets

s.puts(line)


end #of while
puts 'QUIT'

t.join

s.close

Process.exit

end #of con




end #of class


st = Client.new



Server

require 'socket'
require 'thread'

class ServerThread

def initialize

t = TCPServer.new('localhost', 40000)


while(true)

go = t.accept


s = Thread.new(go) do |v|


while(true)


# data = "none"


data = v.gets


v.write(data)



if(data == nil)
puts("From inside if")
self.closeSocket(v)

end #of if


end # while

end #of thread

end #end of while

s.join

end #of constructor

def closeSocket(sock)

puts("This is closeSocket")

sock.close

end #of method

end #of class


s = ServerThread.new



Thanks Ian


 
Reply With Quote
 
 
 
 
James Tucker
Guest
Posts: n/a
 
      01-04-2008
STDIN.gets blocks hard on windows - that is, it blocks at the "c
level" which blocks all running green threads.

The result is this 'lag' behavior - in fact what is happening normally
is that you're not getting any running threads or socket reads except
in the time between gets returning a value, and being called again.

If you avoid $stdin, you will find that the flow is smooth.

Oh, and $stdout blocks too...

There's a video here that sort of demonstrates this in a visual way:

http://blog.ra66i.org/wp-content/net...otator_fun.swf

One side is an echo server, which reverses the string it echos, and
the other is a generator, which generates strings with a moving # in
them. "I" and "O" have meaning local to the respective application.
The right hand side is the generator, the left hand side is the
reversing echo server.

Those were actually built on top of EM, but it's the same issue you see.

On 4 Jan 2008, at 06:00, http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:

> Hi
> I've just started using ruby and thought I'd do some experimenting
> with TCPSocket and TCPServer
>
> I've got a small problem, in that the program I've written runs fine
> on Linux, but runs with a lag on windows. By this I mean that when you
> type into the client on std input in Linux, what you type is
> automatically displayed.
> However in windows nothing happens until you type and send something
> else. Like it's caught in a buffer and needs to be flushed. I've tried
> flushing the output stream as you would in Java, but nothing seems to
> work
> If anyone could give me some advice I would be eternally grateful.
> I've searched around the net, but to no avail.
>
> Client
>
> require 'socket'
> require 'thread'
>
> class Client
>
> def initialize
>
> host = 'localhost'
> port = 40000
>
> s = TCPSocket.new(host, 40000)
>
>
> t = Thread.new do
>
> while(true)
>
> line = s.gets
>
> if(line == nil)
> puts("Program is exiting")
> break
> end #of if
>
> $stdout.flush
>
>
>
> puts "Received: #{line}"
>
>
>
> $stdout.flush
>
> end #of while
>
> s.close
>
> end #of thread
>
> while(true)
>
> puts("About to run stdin")
>
> line = $stdin.gets
>
> s.puts(line)
>
>
> end #of while
> puts 'QUIT'
>
> t.join
>
> s.close
>
> Process.exit
>
> end #of con
>
>
>
>
> end #of class
>
>
> st = Client.new
>
>
>
> Server
>
> require 'socket'
> require 'thread'
>
> class ServerThread
>
> def initialize
>
> t = TCPServer.new('localhost', 40000)
>
>
> while(true)
>
> go = t.accept
>
>
> s = Thread.new(go) do |v|
>
>
> while(true)
>
>
> # data = "none"
>
>
> data = v.gets
>
>
> v.write(data)
>
>
>
> if(data == nil)
> puts("From inside if")
> self.closeSocket(v)
>
> end #of if
>
>
> end # while
>
> end #of thread
>



 
Reply With Quote
 
 
 
 
Francis Cianfrocca
Guest
Posts: n/a
 
      01-04-2008
[Note: parts of this message were removed to make it a legal post.]

On Jan 4, 2008 10:01 AM, James Tucker <(E-Mail Removed)> wrote:

> STDIN.gets blocks hard on windows - that is, it blocks at the "c
> level" which blocks all running green threads.
>
> The result is this 'lag' behavior - in fact what is happening normally
> is that you're not getting any running threads or socket reads except
> in the time between gets returning a value, and being called again.
>
> If you avoid $stdin, you will find that the flow is smooth.
>
> Oh, and $stdout blocks too...
>
> There's a video here that sort of demonstrates this in a visual way:
>
> http://blog.ra66i.org/wp-content/net...otator_fun.swf
>
> One side is an echo server, which reverses the string it echos, and
> the other is a generator, which generates strings with a moving # in
> them. "I" and "O" have meaning local to the respective application.
> The right hand side is the generator, the left hand side is the
> reversing echo server.
>
> Those were actually built on top of EM, but it's the same issue you see.
>
>


The generic answer that EM would provide is: "don't use threads at all."
Unfortunately, at the current time, there is a problem in EM's console
handler that makes event-driven keyboard input unreliable on Windows. We
ought to solve this problem asap.

 
Reply With Quote
 
Luis Lavena
Guest
Posts: n/a
 
      01-04-2008
On 4 ene, 13:14, Francis Cianfrocca <(E-Mail Removed)> wrote:
>
> The generic answer that EM would provide is: "don't use threads at all."
> Unfortunately, at the current time, there is a problem in EM's console
> handler that makes event-driven keyboard input unreliable on Windows. We
> ought to solve this problem asap.


AFAIK, there was a patch for 1.8 that solved this, but couldn't find
it.

Is related to rb_w32_select (win32/win32.c).

Maybe someone can dig ruby-core mails

Regards,
--
Luis Lavena
 
Reply With Quote
 
James Tucker
Guest
Posts: n/a
 
      01-04-2008

On 4 Jan 2008, at 11:14, Francis Cianfrocca wrote:

> ------=_Part_26026_29096075.1199459699490
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> On Jan 4, 2008 10:01 AM, James Tucker <(E-Mail Removed)> wrote:
>
>> STDIN.gets blocks hard on windows - that is, it blocks at the "c
>> level" which blocks all running green threads.
>>
>> The result is this 'lag' behavior - in fact what is happening
>> normally
>> is that you're not getting any running threads or socket reads except
>> in the time between gets returning a value, and being called again.
>>
>> If you avoid $stdin, you will find that the flow is smooth.
>>
>> Oh, and $stdout blocks too...
>>
>> There's a video here that sort of demonstrates this in a visual way:
>>
>> http://blog.ra66i.org/wp-content/net...otator_fun.swf
>>
>> One side is an echo server, which reverses the string it echos, and
>> the other is a generator, which generates strings with a moving # in
>> them. "I" and "O" have meaning local to the respective application.
>> The right hand side is the generator, the left hand side is the
>> reversing echo server.
>>
>> Those were actually built on top of EM, but it's the same issue you
>> see.
>>
>>

>
> The generic answer that EM would provide is: "don't use threads at
> all."


The video there doesn't use threads. That's a completely "native" EM
stack that uses the protocol code I showed you a few weeks ago. In
fact, it's the demo application I'll be releasing with that protocol.

With or without threads, the problem the OP was describing actually
comes up anyway on Windows, as the console IO code could really do
with being made non-blocking, like it is on *nix. My understanding is
though, that this is non-trivial.

> Unfortunately, at the current time, there is a problem in EM's console
> handler that makes event-driven keyboard input unre


lol, - Is that me or you, or a joke? (the premature termination).

Hmm, Luis got it, looks like it was me, scary. *slaps* Mail.app.

 
Reply With Quote
 
ian@frogcottage.demon.co.uk
Guest
Posts: n/a
 
      01-04-2008
On 4 Jan, 15:35, James Tucker <(E-Mail Removed)> wrote:
> On 4 Jan 2008, at 11:14, Francis Cianfrocca wrote:
>
>
>
> > ------=_Part_26026_29096075.1199459699490
> > Content-Type: text/plain; charset=ISO-8859-1
> > Content-Transfer-Encoding: 7bit
> > Content-Disposition: inline

>
> > On Jan 4, 2008 10:01 AM, James Tucker <(E-Mail Removed)> wrote:

>
> >> STDIN.gets blocks hard on windows - that is, it blocks at the "c
> >> level" which blocks all running green threads.

>
> >> The result is this 'lag' behavior - in fact what is happening
> >> normally
> >> is that you're not getting any running threads or socket reads except
> >> in the time between gets returning a value, and being called again.

>
> >> If you avoid $stdin, you will find that the flow is smooth.

>
> >> Oh, and $stdout blocks too...

>
> >> There's a video here that sort of demonstrates this in a visual way:

>
> >>http://blog.ra66i.org/wp-content/net...otator_fun.swf

>
> >> One side is an echo server, which reverses the string it echos, and
> >> the other is a generator, which generates strings with a moving # in
> >> them. "I" and "O" have meaning local to the respective application.
> >> The right hand side is the generator, the left hand side is the
> >> reversing echo server.

>
> >> Those were actually built on top of EM, but it's the same issue you
> >> see.

>
> > The generic answer that EM would provide is: "don't use threads at
> > all."

>
> The video there doesn't use threads. That's a completely "native" EM
> stack that uses the protocol code I showed you a few weeks ago. In
> fact, it's the demo application I'll be releasing with that protocol.
>
> With or without threads, the problem the OP was describing actually
> comes up anyway on Windows, as the console IO code could really do
> with being made non-blocking, like it is on *nix. My understanding is
> though, that this is non-trivial.
>
> > Unfortunately, at the current time, there is a problem in EM's console
> > handler that makes event-driven keyboard input unre

>
> lol, - Is that me or you, or a joke? (the premature termination).
>
> Hmm, Luis got it, looks like it was me, scary. *slaps* Mail.app.


Hi thanks for the answers. I removed the stdin line and replaced it
with gets, and it still has the same error.
Can I take it Ruby Sockets don't work very well with windows?
Big disadvantage if that's true, as it's so often compared to Java,
and it's claimed that it's multi platform.
I'm not sure what all the "EM" stuff means, is that some windows
thing?

Thanks again, but I'm still non the wiser
Ian
 
Reply With Quote
 
Francis Cianfrocca
Guest
Posts: n/a
 
      01-05-2008
[Note: parts of this message were removed to make it a legal post.]

On Jan 4, 2008 4:34 PM, <(E-Mail Removed)> wrote:

> Hi thanks for the answers. I removed the stdin line and replaced it
> with gets, and it still has the same error.
> Can I take it Ruby Sockets don't work very well with windows?
> Big disadvantage if that's true, as it's so often compared to Java,
> and it's claimed that it's multi platform.
> I'm not sure what all the "EM" stuff means, is that some windows
> thing?
>
> Thanks again, but I'm still non the wiser
> Ian
>
>


"EM" is EventMachine: http://rubyforge.org/projects/eventmachine/

 
Reply With Quote
 
Luis Lavena
Guest
Posts: n/a
 
      01-05-2008
On 4 ene, 19:30, (E-Mail Removed) wrote:
> On 4 Jan, 15:35, James Tucker <(E-Mail Removed)> wrote:
>
>
>
> > On 4 Jan 2008, at 11:14, Francis Cianfrocca wrote:

>
> > > ------=_Part_26026_29096075.1199459699490
> > > Content-Type: text/plain; charset=ISO-8859-1
> > > Content-Transfer-Encoding: 7bit
> > > Content-Disposition: inline

>
> > > On Jan 4, 2008 10:01 AM, James Tucker <(E-Mail Removed)> wrote:

>
> > >> STDIN.gets blocks hard on windows - that is, it blocks at the "c
> > >> level" which blocks all running green threads.

>
> > >> The result is this 'lag' behavior - in fact what is happening
> > >> normally
> > >> is that you're not getting any running threads or socket reads except
> > >> in the time between gets returning a value, and being called again.

>
> > >> If you avoid $stdin, you will find that the flow is smooth.

>
> > >> Oh, and $stdout blocks too...

>
> > >> There's a video here that sort of demonstrates this in a visual way:

>
> > >>http://blog.ra66i.org/wp-content/net...otator_fun.swf

>
> > >> One side is an echo server, which reverses the string it echos, and
> > >> the other is a generator, which generates strings with a moving # in
> > >> them. "I" and "O" have meaning local to the respective application.
> > >> The right hand side is the generator, the left hand side is the
> > >> reversing echo server.

>
> > >> Those were actually built on top of EM, but it's the same issue you
> > >> see.

>
> > > The generic answer that EM would provide is: "don't use threads at
> > > all."

>
> > The video there doesn't use threads. That's a completely "native" EM
> > stack that uses the protocol code I showed you a few weeks ago. In
> > fact, it's the demo application I'll be releasing with that protocol.

>
> > With or without threads, the problem the OP was describing actually
> > comes up anyway on Windows, as the console IO code could really do
> > with being made non-blocking, like it is on *nix. My understanding is
> > though, that this is non-trivial.

>
> > > Unfortunately, at the current time, there is a problem in EM's console
> > > handler that makes event-driven keyboard input unre

>
> > lol, - Is that me or you, or a joke? (the premature termination).

>
> > Hmm, Luis got it, looks like it was me, scary. *slaps* Mail.app.

>
> Hi thanks for the answers. I removed the stdin line and replaced it
> with gets, and it still has the same error.


I/O operations are blocking thread in 1.8 (this under Windows)

> Can I take it Ruby Sockets don't work very well with windows?


I commented that was a patch for rb_w32_select on ruby-core or
rubyforge tracker but couldn't find it.

I think like most of the patches hanging there, they get ignored.

Maybe I should start learning japanesse and hang on ruby-dev

Regards,
--
Luis Lavena
 
Reply With Quote
 
James Tucker
Guest
Posts: n/a
 
      01-05-2008
Ian,

Read slowly:

On 4 Jan 2008, at 17:34, (E-Mail Removed) wrote:

> On 4 Jan, 15:35, James Tucker <(E-Mail Removed)> wrote:
>> On 4 Jan 2008, at 11:14, Francis Cianfrocca wrote:
>>> On Jan 4, 2008 10:01 AM, James Tucker <(E-Mail Removed)> wrote:

>>
>>>> STDIN.gets blocks hard on windows - that is, it blocks at the "c
>>>> level" which blocks all running green threads.

>>
>>>> The result is this 'lag' behavior - in fact what is happening
>>>> normally
>>>> is that you're not getting any running threads or socket reads
>>>> except
>>>> in the time between gets returning a value, and being called again.

>>
>>>> If you avoid $stdin, you will find that the flow is smooth.

>>
>>>> Oh, and $stdout blocks too...

>>
>>>> There's a video here that sort of demonstrates this in a visual
>>>> way:

>>
>>>> http://blog.ra66i.org/wp-content/net...otator_fun.swf
>>>

>> With or without threads, the problem the OP was describing actually
>> comes up anyway on Windows, as the console IO code could really do
>> with being made non-blocking, like it is on *nix. My understanding is
>> though, that this is non-trivial.

>
> Hi thanks for the answers. I removed the stdin line and replaced it
> with gets, and it still has the same error.


gets *is* $stdin.gets.

> Can I take it Ruby Sockets don't work very well with windows?


Sockets work fine.

Console I/O is where the problem is.

> Big disadvantage if that's true, as it's so often compared to Java,
> and it's claimed that it's multi platform.


I have production (threaded) apps that do not read from $stdin running
over windows sockets under reasonable load, with no problems
whatsoever. Ruby has been a great multi-platform solution for us, with
the same apps running on *nix, Windows and OS X with no platform issues.

> Thanks again, but I'm still non the wiser


Remove your user input altogether, and *generate* the data instead of
reading it from input, and you will no longer see any issues with the
'smoothness' of your runtime.

> Ian



 
Reply With Quote
 
F. Senault
Guest
Posts: n/a
 
      01-05-2008
Le 5 janvier 2008 11:58, James Tucker a crit :

> On 4 Jan 2008, at 17:34, (E-Mail Removed) wrote:


>> Hi thanks for the answers. I removed the stdin line and replaced it
>> with gets, and it still has the same error.

>
> gets *is* $stdin.gets.


I know it has no bearing to your current point, but this is unaccurate.

Kernel.gets will read from a file if there's something specified on the
command line (ARGV).

I've been bitten by this recently : I had a small script asking
questions from the command line ; then, I tried to add somes switches to
it, and I wondered why I had the message "in `gets': No such file or
directory - -t (Errno::ENOENT)"...

Fred
--
Full-size scottish highland pipes are loud enough to fall into the
category of 'weaponry', especially if they're played poorly, but it's an
analogue of heavy metal if they're played well.
(Gary S. Callison in the SDM)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[Sockets] Problem with ObjectInput/OutputStream Louis Cyphre Java 7 04-13-2005 08:41 AM
Problem: sockets Manuel Hegemann C++ 3 04-27-2004 05:18 PM
Strange problem with System.Net.Sockets.TcpClient() Torsten Brasch ASP .Net 5 01-07-2004 04:51 AM
Problem of throwing an exception (System.Net.Sockets.OverlappedAsyncResult::CompletionPortCallback) VincentWong ASP .Net 1 12-29-2003 09:32 AM
java sockets problem Leo Java 2 09-30-2003 05:21 PM



Advertisments