Beijer Electronics (formerly QSI Corporation)
http://www.qsiforums.com/

Ethernet error
http://www.qsiforums.com/viewtopic.php?f=6&t=3883
Page 1 of 1

Author:  Fonzy [ Fri Sep 18, 2009 11:11 am ]
Post subject:  Ethernet error

Hello,

Can you please tell me what this ethernet error means?

Net open. No free transmission channel (#16)

Thanks

Author:  Jeremy [ Fri Sep 18, 2009 3:13 pm ]
Post subject:  Re: Ethernet error

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.

Author:  Fonzy [ Mon Sep 21, 2009 4:45 am ]
Post subject:  Re: Ethernet error

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

Author:  Jeremy [ Mon Sep 21, 2009 7:36 am ]
Post subject:  Re: Ethernet error

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?

Author:  Fonzy [ Mon Sep 21, 2009 1:53 pm ]
Post subject:  Re: Ethernet error

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.

Author:  Jeremy [ Mon Sep 21, 2009 2:29 pm ]
Post subject:  Re: Ethernet error

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.

Author:  Fonzy [ Thu Sep 24, 2009 2:08 pm ]
Post subject:  Re: Ethernet error

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

Author:  Jeremy [ Thu Sep 24, 2009 2:28 pm ]
Post subject:  Re: Ethernet error

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.

Author:  Fonzy [ Thu Oct 01, 2009 7:32 am ]
Post subject:  Re: Ethernet error

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

Author:  Jeremy [ Thu Oct 01, 2009 8:21 am ]
Post subject:  Re: Ethernet error

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.

Author:  Fonzy [ Thu Oct 01, 2009 8:43 am ]
Post subject:  Re: Ethernet error

Is there a way to trap for the error? Now I get the green screen of death.

Author:  Jeremy [ Thu Oct 01, 2009 9:16 am ]
Post subject:  Re: Ethernet error

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

Author:  Fonzy [ Thu Oct 01, 2009 12:22 pm ]
Post subject:  Re: Ethernet error

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

Author:  Jeremy [ Thu Oct 01, 2009 12:37 pm ]
Post subject:  Re: Ethernet error

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.

Author:  Fonzy [ Thu Oct 01, 2009 1:40 pm ]
Post subject:  Re: Ethernet error

Jeremy,

That did it. The while loop caught the exception.

Thanks,
Joe

Page 1 of 1 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/