Any problems with connecting 400+ telnet 5250 sessions through a WAN to a central server?

15 pts.
Tags:
AS/400
Bandwidth
IBM
Telnet
I am researching a project that would require 400+ IBM 5250 telnet sessions to connect back to a central AS400 server than an MPLS WAN.
  1. Does anyone see any routing / general issues with having this many connection ultimately coming back through 1 router at the host?
  2. How much bandwidth will each session require while idle? Is there a 'minimum' reserved amount of data required while the session is active, even if on the log in screen?
Your feedback / response is greatly appreciated. Thanks Chad

Answer Wiki

Thanks. We'll let you know when a new response is added.

This configuration is pretty normal and 5250 telnet traffic is pretty small and no traffic traverses the wire unless there are keystrokes or the remote host is updating the screen. However, some questions you also need answers to:

  1. What other applications are using this connection? Will these applications create slow telnet session responses? For example, when you type a character in a telnet session, it gets sent to the server and echoed back to the workstation. How much lag response is appropriate? Are the users in China and the host server in the US? This could be an issue.
  2. What about printing? Is the remote host sending back print jobs to the users local printers? This is likely going to be a much larger contribution to network usage than the telnet sessions themselves.
  3. Are these 400+ users using the system all at the same time or are they doing some type of shiftwork where only a percentage will be online and active at any one time? This will also contribute to how large your network links need to be.

My recommendation is to have at least bonded T1’s (2 x 1.5Mbps) links at each end. As I noted in question #1, you need to understand what other applications are also using this link, and question #2 – how is printing done.

You can get some metrics for user sessions by using a packet capture tool like Wireshark and capturing traffic during specific transactions. Calculate the number of transactions per user / per hour and this will give you an estimate of how much bandwidth you need during high usage windows.

Discuss This Question: 4  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Genxsherpa
    Thanks for the feedback Labnuke. To further explain our current configuration: There are 23 remote sites with 20-40 5250 sessions each, all connecting back to a central AS400 using 'thin client' devices. Each location has a Full T1, while the host connection has a full DS3 all running through MPLS. 1) Other than the 5250 sessions, local Intranet, Internet access, and remote desktop connections will traverse the same connection. CoS will be implemented to allocate bandwidth priority to the 5250 sessions. All locations are within 150 miles of the host. 2) All print jobs will be spooled from the remote location to the host site. We have CoS implemented allocating bandwidth priority to the 5250 sessions and print jobs. 3) It is not likely that all 400 sessions will be firing at once, but that is dependent on the day. Located in a retail environment, weekends will provide the heaviest use of the terminals. Thanks Chad
    15 pointsBadges:
    report
  • graybeard52
    fwiw, We have 11 remote sites with varying numbers of 5250 sessions connecting back to a central site. Probably just about 400 sessions. We also have internet, intranet, VoIP, and GUI apps running across the same lines. We have bonded T1's (2x1.5) at host site, remote vary from 512 to 1.5. The 5250 bandwidth doesn't even show on the charts its is so small. If you have issues, it will the the other stuff.
    3,115 pointsBadges:
    report
  • Labnuke99
    I agree with Graybeard - your configuration should be adequate. You can put some priority queueing on the 5250 traffic but it likely will not add much performance to the link. Quality of Service (QOS) & Class of Service (COS) may be important also to keep this telnet traffic from being bandwidth starved by other traffic. However, this may be an additional upcharge by your carrier. You should be fine to begin with, but if you find sessions being slow and sluggish, consider adding QOS/COS to the link to carve out some dedicated bandwidth for your business application(s).
    32,960 pointsBadges:
    report
  • TomLiotta
    ...when you type a character in a telnet session, it gets sent to the server and echoed back to the workstation. How much lag response is appropriate? Just a minor comment on this -- This is not true for TN5250 telnet sessions. Clients will transfer and receive entire screens in blocks. Communication is 'block mode'. No characteras are sent to the host until an <Enter> or other function key is pressed; then all characters that have been input are sent in a block transmission. A similar technology happens when screens are returned from the host. There is no 'echo' of individual characters. For the question, 400 telnet sessions will probably never take as much bandwidth as downloading a single web page from this Techtarget site. I wouldn't be concerned. Tom
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following