Yun Server on two different ports

I have a common task where I want to communicate with the 32U4 from a PC app via a raw TCP socket. At the same time I would like to run a webpage off the SD card from the AR9331 displaying data from the sketch. I am able to make this work in two separate programs; one communicating on a port(1000) to the PC terminal, the other replies to the web page using zepto, port 6571. When I try to run two servers combined into one script on different ports the second one to initiate shuts down the first. I have servers and clients with different names in the script. Is it possible to run Yun Server twice? Or run Yun Clients on different ports?
Thanks for any tips.

Example of code:

YunServer webserver;
YunClient webclient;
YunServer telserver(1000);
YunClient telclient(1000);

void setup() {

     // Telnet startup
  telserver.noListenOnLocalhost();
  telserver.begin();
  telclient = telserver.accept();
  
    // HTTP Network startup
  Bridge.begin();
  webserver.listenOnLocalhost();
  webserver.begin();

  Console.begin();

You are calling Bridge.begin() in the middle of your initialization sequence. It must come first. I'll bet that what's happening is you are starting to set up the first server, then you call Bridge.begin() which initializes things inside the Bridge library, and you lose the improperly initialized first server. The second server works, because it was initialized after the Bridge was initialized.

You asked for any tips: my tip is don't try to do all of this in the sketch. The Linux side is much more powerful and efficient when it comes to setting up networked applications. It is also much faster and does not have the same RAM and ROM space limitations as the sketch side of the Yun.

My philosophy when it comes to Yun applications is to do as much as possible on the Linux side, and just use the sketch as a dumb I/O processor that handles the communications with the shield I/O pins.

Many thanks for your comments ShapeShifter, your help goes a long ways on these forums.

I see the problem with Bridge.begin() in the wrong order. Yet this doesn't affect the issue.
I've tried a few more attempts at this challenge and it seems anytime "if (client)" is called the response is always true whether it's telclient or client that has a connection. It looks like only one port can be connected.

I would prefer to do a bit more processing on the Linux side, but two issue come up: my abilities and understanding to do this, and concern over response time for I/O to react to socket commands. I am looking at using a socket for a direct TCP connection to the 32U4 and using Bridge.put to move data to the AR9331 for web display.

cous:
and concern over response time for I/O to react to socket commands.

And that's exactly why I make my recommendation. Performing network operations in the sketch is easy, but quite slow: in reality, the connection comes into Linux, which pre-processes it rather quickly. Then the connection data is sent over the relatively slow serial port up to the sketch, then the very slow AVR processor must handle the data, send any confirmation or response down the serial port, and the LFirst mud can finish up the operation. You are already passing everything through Linux, and you are sending ALL of the communications data and overhead.

If you learn to play implement it on the Linux side, and just send the final digested information upmtomthe sketch, it is likely to be much faster overall. My suggestion is to start simple, and look at something like the Flask or Bottle frameworks that run in Python (I use Bottle.) Use that to handle the web service, and keep your telnet socket in the sketch for now. I write the Bottle application as a Python script, and use the Process class to launch it. That way, all the Python code needs to do is "print" any output for the sketch, and the sketch can read that output from the Process object.