VanDyke Software Forums

Go Back   VanDyke Software Forums > SecureCRT 5.1/SecureFX 3.1/VShell 2.6 Beta
User Name
Password
Register FAQ Members List Calendar Search Today's Posts Mark Forums Read

 
 
Thread Tools Display Modes
  #1  
Old 06-07-2005, 01:19 PM
Crossman Crossman is offline
Registered User
 
Join Date: Jun 2005
Posts: 3
SecureCRT problem with buffer

Appears that whether I paste a large amount of data to the connection or use the send ASCII file to send the same file I have the same problem. It appears that after the 50th line of text the information starts getting corrupted with messed up characters. The ASCII file is in either a .doc format or a .txt format.
  #2  
Old 06-07-2005, 02:23 PM
toloughlin's Avatar
toloughlin toloughlin is offline
Senior Member
 
Join Date: Feb 2004
Location: Nashua, NH
Posts: 378
Which build of SecureCRT are you running? Which OS?
I tried this running build 974 (send ascii & paste) and could not reproduce. I'm on Win2K SP4, going to a SuSE linux box.
__________________
----------------------------------------------
Tom O'Loughlin
  #3  
Old 06-14-2005, 11:54 AM
Crossman Crossman is offline
Registered User
 
Join Date: Jun 2005
Posts: 3
We are using build 974 on Windows XP Pro Version 2002 SP1. We are connecitng to a Cisco 2514 router via com port 1.
  #4  
Old 06-14-2005, 06:16 PM
Maureen's Avatar
Maureen Maureen is offline
VanDyke Product Director
 
Join Date: Feb 2004
Location: Albuquerque, NM
Posts: 1,585
What protocol is your session using? Did this used to work in previous versions?

Maureen
  #5  
Old 06-14-2005, 06:48 PM
toloughlin's Avatar
toloughlin toloughlin is offline
Senior Member
 
Join Date: Feb 2004
Location: Nashua, NH
Posts: 378
Maureen, it'd be a serial connection (protocol), via the COM port.

I tried pasting about 57 lines of config into an older 2924 switch ...

The paste seemed to get cut off - like a buffer reached ... I don't know at what point. But no garble.

The send ASCII - seemed to work OK.

Crossman, are you running Beta 7 these days?
__________________
----------------------------------------------
Tom O'Loughlin
  #6  
Old 06-15-2005, 08:36 AM
Shane's Avatar
Shane Shane is offline
Registered User
 
Join Date: Jun 2005
Posts: 3
SecureCRT problem with buffer

I've seen similar problems with version 3 and now with version 5, Beta 6 & 7. (not sure on version 4 as I never used it.) Setting the Global> Terminal> Character Send Delay option to 1 milllisecond seems to fix this in version 5, but that seems like a work-around and not a solution. Hope this helps.
__________________
Shane
"Success has a thousand fathers. Failure is an orphan."
  #7  
Old 06-15-2005, 04:02 PM
Maureen's Avatar
Maureen Maureen is offline
VanDyke Product Director
 
Join Date: Feb 2004
Location: Albuquerque, NM
Posts: 1,585
Quote:
Originally Posted by Crossman
Appears that whether I paste a large amount of data to the connection or use the send ASCII file to send the same file I have the same problem. It appears that after the 50th line of text the information starts getting corrupted with messed up characters. The ASCII file is in either a .doc format or a .txt format.
Does changing the character send delay as Shane suggested change the behavior at all?

Maureen
  #8  
Old 06-15-2005, 05:56 PM
Crossman Crossman is offline
Registered User
 
Join Date: Jun 2005
Posts: 3
Shane and I work together and this was the workaround we used. Thanks
  #9  
Old 06-21-2005, 11:06 AM
Shane's Avatar
Shane Shane is offline
Registered User
 
Join Date: Jun 2005
Posts: 3
Question

Is this a line or buffer limitation? We frequently copy and paste config files that are as long as 300 lines.
__________________
Shane
"Success has a thousand fathers. Failure is an orphan."
  #10  
Old 06-22-2005, 10:29 AM
bocks's Avatar
bocks bocks is offline
VanDyke Customer Support
 
Join Date: Jan 2004
Location: Albuquerque, NM
Posts: 184
Quote:
Originally Posted by Shane
Is this a line or buffer limitation? We frequently copy and paste config files that are as long as 300 lines.
At the root, this is a combination of two problems: buffer size and transmission speed.

You are correct in that the buffer is filling up and then losing data, but the reason that the buffer is filling up is due to the transmission speed. Data is coming in faster than it can be processed. When you add a line or character send delay, you are effectively slowing down the transfer rate of the data. This allows the buffer to keep up with both the incoming and outbound data (by which I mean the rate at which and application pulls data from the buffer.) The line send delay is usefull if the system processes a line at a time, and only a small delay is needed. By using a character send delay, you can dramatically affect the overall transmission speed because the delay is used after each and every character is sent.

The effective data transfer rate is affected by the serial port speed and the speed of the system pulling the data. If the serial speed does not exceed the speed of the data pulling speed, there will not be a problem. If the inbound data is higher than the outband data rate, the buffer will fill. Once it is full, it will start to drop data, resulting in the garbled text.

Does this help to clarify the cause of this behavior?

-bocks
  #11  
Old 06-28-2005, 10:36 AM
Shane's Avatar
Shane Shane is offline
Registered User
 
Join Date: Jun 2005
Posts: 3
This explains the behavior, but is the solution I proposed, inserting a character send delay, the only solution to the problem? (Increasing the line delay with no character delay doesn't work) Is there a different solution, more global and long term that could be implemented?

Thanks for the feedback.
__________________
Shane
"Success has a thousand fathers. Failure is an orphan."
  #12  
Old 06-30-2005, 08:39 AM
bocks's Avatar
bocks bocks is offline
VanDyke Customer Support
 
Join Date: Jan 2004
Location: Albuquerque, NM
Posts: 184
Quote:
This explains the behavior, but is the solution I proposed, inserting a character send delay, the only solution to the problem?
At this point in time, adding a character send delay is probably the only real solution unless you are using a serial connection where you can control the baud rate.

Even setting the baud rate is basically sending data using predefined delays between data bits ( I know this is a rather simplistic view, but without looking at the lower serial protocolols, it is somewhat accurate).

What I would suggest is starting with a medium to large character send delay of say 200ms. If you do not see any problems, then drop it by 20% to 50%. If you still see the same behavior, then raise the delay by the same amount. Once you see a change in behavior, you can adjust it up or down by smaller amounts to determine the optimal settings.

If the problem is not so much the transmission speed but the buffer size, and the information that you are sending is regularly delimited by a line feed, then a larger line send delay may meet your needs. For the line send delay, you would follow the same process to determine the proper delay, but you would need to start with a larger value. Say 300ms to 500ms.

Quote:
Is there a different solution, more global and long term that could be implemented?
This leads to an important point. Since character and line send delays are part of the Global options, they will affect ALL of your sessions.

As to a different solution, I think that this will depend on where you feel the error is. If you are looking at a client side solution, then you need to throttle the transmission speed to a level that the server can handle. This would be the character and line send delays that we have been discussing.

If you are looking at a server side solution, you would need to either increase the size of the buffer to the point that it will compensate for the difference in transmission speed versus data procesing speed, or you you will need to increase the system's ability to pull data from the buffer and process it.

Does this give you some options that you can use?

-bocks
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

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

Forum Jump


All times are GMT -6. The time now is 05:46 PM.


copyright 1995-2017 VanDyke Software, Inc.