vb application hangs

  • Thread starter Thread starter friend
  • Start date Start date
F

friend

Hello all,
I am implementing a tool which can send and receive the data from the
remotehost...
while sending the data, if i send large amount of data at once my
application hangs..
and after everything has been send to remote system then my
application works...but mean while transferring the data the
application hangs...

how to resolve this issue ??


Please help me ....thanks to all
 
friend said:
Hello all,
I am implementing a tool which can send and receive the data from the
remotehost...
while sending the data, if i send large amount of data at once my
application hangs..
and after everything has been send to remote system then my
application works...but mean while transferring the data the
application hangs...

how to resolve this issue ??
Click to expand...


You mean, your user interface doesn't respond? Then send the data in another
thread.


Armin
 
friend said:
Hello all,
I am implementing a tool which can send and receive the data from the
remotehost...
while sending the data, if i send large amount of data at once my
application hangs..
and after everything has been send to remote system then my
application works...but mean while transferring the data the
application hangs...

how to resolve this issue ??
Click to expand...


You mean, your user interface doesn't respond? Then send the data in another
thread.


Armin
 
friend said:
Hello all,
I am implementing a tool which can send and receive the data from the
remotehost...
while sending the data, if i send large amount of data at once my
application hangs..
and after everything has been send to remote system then my
application works...but mean while transferring the data the
application hangs...

how to resolve this issue ??


Please help me ....thanks to all
Click to expand...

How you are sending? direct sockets, html request?

In general, in communications you have a basic principle

Send Low
Receive High

The theory is that you don't know what the receiver can handle, so you
send small chunks. But for receiving, you are in full control in
knowing what you can handle so you can afford reading large chunks.
It is basis for efficient and optimal data transfers.

If you are familiar with the IETF, the principle is best said with the
Jon Postel's axiom for robust protocol design:

Be conservative in what you send, liberal in what you receive.

The reason why your application main thread is more responsive with
smaller chunks is because the send data command has completed its
work, it is no longer blocked.

The large the chunk, the more time it needs to transfer the data which
will most likely include hardware flow control requirements, it will
block so your main thread is less responsive.

As others have suggested, using a background task or thread can help
alleviate the problem. But even the background task/thread should
take into account of sending smaller chunks.

Remember, if this a socket (internet) application, the socket is
limited to a fixed size, 4 to 8K is the general default size and to
best understand how to get an optimal transfer is to look at it as a
chain or Firemen Bucket Brigade.

WATER FIREMAN MAN CHILD FIRE
SOURCE --> BUCKET --> BUCKET --> BUCKET --> ... TARGET

You don't want anyone in the brigade to slow down the transfer of
water. You don't want half filled buckets (data size too small) and
you don't want to over fill because there is a max bucket size anyway.

Overfills, would be like each person having a overfill spill buckets:

SOURCE --> BUCKET --> BUCKET --> BUCKET --> ... TARGET
BUCKET BUCKET BUCKET BUCKET

That that will force a slow down because each person will have to stop
the previous person so he can finish passing all his buckets including
the spill buckets. This is the essence of data transfer sychronization
controls and in Windows parley "Overlapped I/O"

So you use a standard data transfer size so you can get a beautiful
synchronize flow of buckets in the brigade.

Note: A background thread/task is still recommended so that that your
main thread is not bogged down and can be more responsive.

Hope this provide some insight into why its happening.

--
 
friend said:
Hello all,
I am implementing a tool which can send and receive the data from the
remotehost...
while sending the data, if i send large amount of data at once my
application hangs..
and after everything has been send to remote system then my
application works...but mean while transferring the data the
application hangs...

how to resolve this issue ??


Please help me ....thanks to all
Click to expand...

How you are sending? direct sockets, html request?

In general, in communications you have a basic principle

Send Low
Receive High

The theory is that you don't know what the receiver can handle, so you
send small chunks. But for receiving, you are in full control in
knowing what you can handle so you can afford reading large chunks.
It is basis for efficient and optimal data transfers.

If you are familiar with the IETF, the principle is best said with the
Jon Postel's axiom for robust protocol design:

Be conservative in what you send, liberal in what you receive.

The reason why your application main thread is more responsive with
smaller chunks is because the send data command has completed its
work, it is no longer blocked.

The large the chunk, the more time it needs to transfer the data which
will most likely include hardware flow control requirements, it will
block so your main thread is less responsive.

As others have suggested, using a background task or thread can help
alleviate the problem. But even the background task/thread should
take into account of sending smaller chunks.

Remember, if this a socket (internet) application, the socket is
limited to a fixed size, 4 to 8K is the general default size and to
best understand how to get an optimal transfer is to look at it as a
chain or Firemen Bucket Brigade.

WATER FIREMAN MAN CHILD FIRE
SOURCE --> BUCKET --> BUCKET --> BUCKET --> ... TARGET

You don't want anyone in the brigade to slow down the transfer of
water. You don't want half filled buckets (data size too small) and
you don't want to over fill because there is a max bucket size anyway.

Overfills, would be like each person having a overfill spill buckets:

SOURCE --> BUCKET --> BUCKET --> BUCKET --> ... TARGET
BUCKET BUCKET BUCKET BUCKET

That that will force a slow down because each person will have to stop
the previous person so he can finish passing all his buckets including
the spill buckets. This is the essence of data transfer sychronization
controls and in Windows parley "Overlapped I/O"

So you use a standard data transfer size so you can get a beautiful
synchronize flow of buckets in the brigade.

Note: A background thread/task is still recommended so that that your
main thread is not bogged down and can be more responsive.

Hope this provide some insight into why its happening.

--
 
You mean, your user interface doesn't respond? Then send the data in another
thread.

Armin
Click to expand...

Yes, my user interface doesnt respond.
Just now i have found the problem. I am using streamwriter to write
the whole string.
and there it is taking time. at the point my userinterface doent
respond
does the backgroundworker solves this ?
 
You mean, your user interface doesn't respond? Then send the data in another
thread.

Armin
Click to expand...

Yes, my user interface doesnt respond.
Just now i have found the problem. I am using streamwriter to write
the whole string.
and there it is taking time. at the point my userinterface doent
respond
does the backgroundworker solves this ?
 
friend said:
Yes, my user interface doesnt respond.
Just now i have found the problem. I am using streamwriter to write
the whole string.
and there it is taking time. at the point my userinterface doent
respond
does the backgroundworker solves this ?
Click to expand...

Yes. Or just a Threading.Thread object.


Armin
 
friend said:
Yes, my user interface doesnt respond.
Just now i have found the problem. I am using streamwriter to write
the whole string.
and there it is taking time. at the point my userinterface doent
respond
does the backgroundworker solves this ?
Click to expand...

Yes. Or just a Threading.Thread object.


Armin
 
friend said:
Yes, my user interface doesnt respond.
Just now i have found the problem. I am using streamwriter to write
the whole string.
and there it is taking time. at the point my userinterface doent
respond
does the backgroundworker solves this ?
Click to expand...

Yes

I am not upto par with VB.NET task and threads, yet <g>, but in
general a TASK is a multi-tasking concept and a THREAD is a concurrent
concept.

In other words, a TASK is still within the main thread (which every
application has) and it deals the simulation of concurrency using task
switching and a message queue. There is no time slicing involved.

A thread is 2nd real CPU context switching thread and it doesn't have
a message queue and it uses pre-emptive time slicing to simulate
concurrency. In multi-core machines you get closer concurrency with
the idea of parallel threads running which requires special design
consideration (if the parallel threads are going to work together).

Here is how to get better performance as a general practice in ALL
languages, using pseudo code:

GUI applications:
- has a main thread which handles the message queue
- the UI uses the message queue

OnForm_ClickButton: Using Message Queue

open file
while not end of file
read string or block
send block/string
Check the Message Queue for CANCEL or ABORT
end while
close file

- Using BackGround Task or Thread

Task
open file
while not end of file
read string or block
send block/string
Check any Main UI Thread Abort Flag
end while
close file
endtask

OnForm_ClickButton:

Start Task

Console Application:

- consoles has one main thread and no message queues
(well in theory it does, the OS wrappers the exe with
a message queue, so you can trap close DOS window, etc.)

- so if you wanted to be response here, you can use
a keep board loop and a SetConsoleCtrlHandler() handler.

Main Block:

prepare SetConsoleCtrlHandler

open file
while not end of file
read string or block
send block/string
Time Slicing Keyboard Loop
check for ESC or some abort key
end while
close file

- Using BackGround Thread

Thread
open file
while not end of file
read string or block
send block/string
Check any Main volatile flag abort flag or
some kernel event flag
end while
close file
end Thread

Main Block:

prepare SetConsoleCtrlHandler
Start Thread
Time Slicing Keyboard Loop check abort key
Signal abort to background thread

--
 
friend said:
Yes, my user interface doesnt respond.
Just now i have found the problem. I am using streamwriter to write
the whole string.
and there it is taking time. at the point my userinterface doent
respond
does the backgroundworker solves this ?
Click to expand...

Yes

I am not upto par with VB.NET task and threads, yet <g>, but in
general a TASK is a multi-tasking concept and a THREAD is a concurrent
concept.

In other words, a TASK is still within the main thread (which every
application has) and it deals the simulation of concurrency using task
switching and a message queue. There is no time slicing involved.

A thread is 2nd real CPU context switching thread and it doesn't have
a message queue and it uses pre-emptive time slicing to simulate
concurrency. In multi-core machines you get closer concurrency with
the idea of parallel threads running which requires special design
consideration (if the parallel threads are going to work together).

Here is how to get better performance as a general practice in ALL
languages, using pseudo code:

GUI applications:
- has a main thread which handles the message queue
- the UI uses the message queue

OnForm_ClickButton: Using Message Queue

open file
while not end of file
read string or block
send block/string
Check the Message Queue for CANCEL or ABORT
end while
close file

- Using BackGround Task or Thread

Task
open file
while not end of file
read string or block
send block/string
Check any Main UI Thread Abort Flag
end while
close file
endtask

OnForm_ClickButton:

Start Task

Console Application:

- consoles has one main thread and no message queues
(well in theory it does, the OS wrappers the exe with
a message queue, so you can trap close DOS window, etc.)

- so if you wanted to be response here, you can use
a keep board loop and a SetConsoleCtrlHandler() handler.

Main Block:

prepare SetConsoleCtrlHandler

open file
while not end of file
read string or block
send block/string
Time Slicing Keyboard Loop
check for ESC or some abort key
end while
close file

- Using BackGround Thread

Thread
open file
while not end of file
read string or block
send block/string
Check any Main volatile flag abort flag or
some kernel event flag
end while
close file
end Thread

Main Block:

prepare SetConsoleCtrlHandler
Start Thread
Time Slicing Keyboard Loop check abort key
Signal abort to background thread

--
 
BTW, the point of my past two post, is that you don't want NEVER want
to send a large data in ONE shot over the wire. You need to HOOK into
the data transfer logic so that you be cooperative with not only
yourself (your applet) but the rest of the Windows applications and
system processes running.

In all cases, you don't use command to send the entire data unless it
provides a mechanism for overlapping I/O

Prepare OverlappedIO Events
WriteStream( data, sizeof(data), OverlappedIO Event Object)
if error is Error_OverlappedIO_Pending then
wait for overlappedio events to finish
end

How you hook into the transfer logic depends largely

- the language exposing the same concepts

- the features of the synch/async data transfer commands

- multitasking (message queues) or concurrent (threads)
processing.


--
 
BTW, the point of my past two post, is that you don't want NEVER want
to send a large data in ONE shot over the wire. You need to HOOK into
the data transfer logic so that you be cooperative with not only
yourself (your applet) but the rest of the Windows applications and
system processes running.

In all cases, you don't use command to send the entire data unless it
provides a mechanism for overlapping I/O

Prepare OverlappedIO Events
WriteStream( data, sizeof(data), OverlappedIO Event Object)
if error is Error_OverlappedIO_Pending then
wait for overlappedio events to finish
end

How you hook into the transfer logic depends largely

- the language exposing the same concepts

- the features of the synch/async data transfer commands

- multitasking (message queues) or concurrent (threads)
processing.


--
 
Mike,

A task was more something from IBM who could not get done what Burroughs did
and so they created a complete new concept.
It was simply cutting a load in parts, but it was not what Burroughs did
with Multiprogramming and either was it the same as threads.

http://en.wikipedia.org/wiki/Multiprogramming

Burroughs computers were to sophisticated for their time. That you could as
well see in the up time of the hardware.

Cor
 
Mike,

A task was more something from IBM who could not get done what Burroughs did
and so they created a complete new concept.
It was simply cutting a load in parts, but it was not what Burroughs did
with Multiprogramming and either was it the same as threads.

http://en.wikipedia.org/wiki/Multiprogramming

Burroughs computers were to sophisticated for their time. That you could as
well see in the up time of the hardware.

Cor
 
Back
Top