Beijer Electronics (formerly QSI Corporation)

Manufacturer of Mobile Data and Human Machine Interface Terminals.
It is currently Fri Nov 24, 2017 12:09 am

All times are UTC - 7 hours




Post new topic Reply to topic  [ 15 posts ] 
Author Message
 Post subject: Ethernet error
PostPosted: Fri Sep 18, 2009 11:11 am 
Offline

Joined: Wed Feb 11, 2009 9:32 am
Posts: 34
Hello,

Can you please tell me what this ethernet error means?

Net open. No free transmission channel (#16)

Thanks


Top
 Profile  
 
 Post subject: Re: Ethernet error
PostPosted: Fri Sep 18, 2009 3:13 pm 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
Qlarity can support a maximum of 64 simulteneous network sessions, of which at most 32 can be TCP.

If you exceed that number you will get the "Net open. No free transmission channel (#16)" error.

There are several ways you can fill that space up that may not be immediately obvious.

  • You can "leak" channels by forgetting to call NetClose
  • Each server (NetServerOpen, NetOpen {called with foreign port of zero}) uses one channel. TCP servers use one of the TCP channels.
  • When you perform the active close on a TCP channel, the channel enters the 2MSL state (google 2MSL). In this state the firmware must keep the channel temporarily open to handle any duplicate packets that may arrive late. This state lasts 1-2 minutes before the TCP channel is fully closed, and can be bypassed if the other side performs the TCP active close.***

Of these, the last bullet is the most common cause that I have seen and the hardest to work around.

*** By active close, I mean any time you call NetClose, except in response to a MSG_COMM_ERROR indicating that the other side closed the connection.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
 Post subject: Re: Ethernet error
PostPosted: Mon Sep 21, 2009 4:45 am 
Offline

Joined: Wed Feb 11, 2009 9:32 am
Posts: 34
Jeremy,

Thanks for the detailed response. My communications object is derived from EthernetClientV2. Is NetClose the same as closeConnection()? If not should I be using NetOpen and NetClose()?

Joe


Last edited by Fonzy on Thu Sep 24, 2009 1:50 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: Ethernet error
PostPosted: Mon Sep 21, 2009 7:36 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
Sorry, I guess I just assumed you were using NetOpen (as that text appeared in the error message).

The EthernetClientV2 should be doing the NetClose automatically for you. I just reviewed the source code and it appears to be doing what I expect.

My guess is that you are falling into the 3rd category (opening and closing too many connections in a short time). Is this something that would make sense to you?

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
 Post subject: Re: Ethernet error
PostPosted: Mon Sep 21, 2009 1:53 pm 
Offline

Joined: Wed Feb 11, 2009 9:32 am
Posts: 34
It's all user controlled. We have a broadcast server that receives information once a second then users can press a button that will open a connection, send a command, wait for a response (which happens fast) and closes the connection.

I guess it depends on what "a lot" means.


Top
 Profile  
 
 Post subject: Re: Ethernet error
PostPosted: Mon Sep 21, 2009 2:29 pm 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
If Qlarity closes more than about 30 TCP connections in a 2 minute period (possibly 1 minute in recent firmware releases, not sure on that though), then this can happen.

If this is your situation, then there are two things you can do to try and obviate the situation. The first, is see if the host you are communicating with can perform the active TCP close. If the other side performs the active TCP close, the EthernetClientV2 object will receive a MSG_COMM_ERROR "Connection closed by foregn host" and will call NetClose in response. In this case the Qlarity firmware is able to immediately reclaim the internal data structures used to host the TCP connection, instead of waiting for 1-2 minutes to do so.

The other alternative is to use a persistent TCP connection. If you will be frequently sending and receiving commands, persisting the TCP connection across multiple commands can result in a significant reduction in processing power and network traffic.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
 Post subject: Re: Ethernet error
PostPosted: Thu Sep 24, 2009 2:08 pm 
Offline

Joined: Wed Feb 11, 2009 9:32 am
Posts: 34
Jeremy,

Is there anyway for the G55 to issue an Active Close on the connection or does it have to come from both parties?

Joe


Top
 Profile  
 
 Post subject: Re: Ethernet error
PostPosted: Thu Sep 24, 2009 2:28 pm 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
This starts to get a bit deep into TCP theory (which is big enough for entire books).

Technically, once a TCP connection is established, both parties need to participate in the shutdown (for a clean shutdown, there are also forcible resets, but they are beyond the scope of what I am discussing here).

In particular, you can only shut down your side of the TCP conversation. When you send a TCP FIN packet, you are essentially promising that you will never speak again. Typically the other side will respond by shutting down its connection as well, although it is possible for the other side to keep the connection half-open and continuing transmitting to you.

When I say "Active Close" I am referring to the party that initiates the shutdown procedure. In Qlarity terms that means if you call NetClose (or in your case CloseConnection(), which in turn, calls NetClose) before the other side closes their half of the TCP connection, you have performed the Active Close and that TCP connection must wait in the 1-2 minute penalty box before the TCP resource can be reclaimed. (This is called the 2MSL period and is dictated by the TCP standard).

However, if the other side starts the shutdown procedure the following will happen to your EthernetClientV2 object.

  • The EthernetClientV2 object will receive a MSG_COMM_ERROR with an error code that indicates that the other side shut down the connection
  • The EthernetClientV2 object will call CloseConnection (which will call NetClose)
  • The EthernetClientV2 will trigger its EthernetError event for you to handle if desired.

In this latter case, 2 MSL period is bypassed and the TCP connection resource is immediately reclaimed.

An excellent example of a protocol that behaves this way is HTTP (think HTTP 1.0, not HTTP 1.1 which has a lot of complicated connection keepalive machinery), especially with the GET action

In HTTP/1.0, the client would open a TCP connection to the server. Once established the client would issue a GET request for a resource. The server would respond with that resource (or an error code) then terminate the connection. This sequence of events is ideal for Qlarity code with its limited number of TCP connections. Actually a limited number of connections is a concern in many embedded devices, as each TCP connection requires a fairly large amount of RAM and we didn't want to remove too much from being available to the application itself.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
 Post subject: Re: Ethernet error
PostPosted: Thu Oct 01, 2009 7:32 am 
Offline

Joined: Wed Feb 11, 2009 9:32 am
Posts: 34
Jeremy,

Thanks for the great explanation of the MSL concept. I did Google it as suggested and your explanation further explains what I read.

To clarify what you wrote the TCP connection limit is system wide not per instance of the EthernetClientV2 object, correct?

Does the G58 have the same limit?

Thanks,

Joe


Top
 Profile  
 
 Post subject: Re: Ethernet error
PostPosted: Thu Oct 01, 2009 8:21 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
The limit of 32 TCP connections is system wide, not per EthernetClientV2 instance.

This limit is in place for all Qlarity based terminals, including the G58.

For future devices which run Qlarity, we are planning on increasing the limit, and possibly removing it entirely, unfortunately it will be a while before that generation of devices is ready.

I remember asking the firmware design lead why they didn't just dynamically allocate TCP resources as needed. He had a good answer, although I don't remember the details why at the moment.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
 Post subject: Re: Ethernet error
PostPosted: Thu Oct 01, 2009 8:43 am 
Offline

Joined: Wed Feb 11, 2009 9:32 am
Posts: 34
Is there a way to trap for the error? Now I get the green screen of death.


Top
 Profile  
 
 Post subject: Re: Ethernet error
PostPosted: Thu Oct 01, 2009 9:16 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
Try

Code:
dim errTyp, errLev as unibyte
dim errStr as string

check error
    MyEthernetClient.OpenConnection()
on error
    GetException(errStr, errTyp, errLev)
    if errTyp <> 0x00A1 then
        'rethrow all errors except EXCEPT_NOFREECHANNEL
        rethrow()
    endif
enderr

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
 Post subject: Re: Ethernet error
PostPosted: Thu Oct 01, 2009 12:22 pm 
Offline

Joined: Wed Feb 11, 2009 9:32 am
Posts: 34
Jeremy,

I overloaded the openConnection method and I get the green screen. Am I missing something?

Thanks,
Joe

Code:
func openConnection()
    check error
        if getConnectionState() == ec_connectionpending then
            networkErrorLabel.value="Unable to connect to the DSCU"
            showNetworkErrorScreen()
        else
            default()
        endif
    on error
        GetException(errorMessage, err1, err2)
        networkErrorLabel.value=errorMessage
        showNetworkErrorScreen()  'displays a window if there is an error
    enderr
endfunc


Top
 Profile  
 
 Post subject: Re: Ethernet error
PostPosted: Thu Oct 01, 2009 12:37 pm 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
Try

Code:
    on error
        networkErrorLabel.value=""

        while GetException(errorMessage, err1, err2) do
            networkErrorLabel.value = networkErrorLabel.value + errorMessage
        loop
        showNetworkErrorScreen()  'displays a window if there is an error
    enderr



And see if that fixes the green screen. (I should probably of had the while in my sample too).

This is especially relevant if you have "Extra Exception Tracking" turned on.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
 Post subject: Re: Ethernet error
PostPosted: Thu Oct 01, 2009 1:40 pm 
Offline

Joined: Wed Feb 11, 2009 9:32 am
Posts: 34
Jeremy,

That did it. The while loop caught the exception.

Thanks,
Joe


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 15 posts ] 

All times are UTC - 7 hours


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group