Hi Suyan
The passive instance is created by first opening a
EFI_TCP4_SERVICE_BINDING_PROTOCOL and then calling CreateChild on that. I pass
a NULL Handle to CreateChild so that the EFI_TCP4_PROTOCOL is installed on a
new handle. When the application exits I call Configure on the passive instance
with NULL for the TcpConfigData (which "brutally resets" the instance), and
then call DestroyChild.
Ideally rather than calling Configure with NULL, I would call Cancel , but as
you can see in Tcp4Main.c, Cancel isn't implemented in EDK2.
Tom:
>My workaround was to set the port to zero, which results in a random port
>being chosen every time
This would certainly solve my problem, but unfortunately the application is a
"server" so it needs to be on a particular port :(
Best,
Brendan
From: Fu, Siyuan [mailto:[email protected]]
Sent: 18 February 2014 02:23
To: Olivier Martin; Brendan Jackman
Cc: [email protected]
Subject: RE: [edk2] TCP->Configure after TCP->Close
Hi, Brendan and Martin
To help understand the problem, could you tell me how does you create or get
the passive TCP instance upon the application start? And have you destroyed
the passive instance before the application exit, or you just leave it in
listen state?
Thanks,
Siyuan
From: Thomas Rognon [mailto:[email protected]]
Sent: Tuesday, February 18, 2014 7:15 AM
To: edk2-devel
Cc: Olivier Martin
Subject: Re: [edk2] TCP->Configure after TCP->Close
I encountered the same issue. My workaround was to set the port to zero, which
results in a random port being chosen every time (which would fail if the same
port was randomly chosen, though the odds are very low). The port didn't matter
in my application, but this would be unacceptable in many other applications.
I'm also curious if this is a bug or if I'm doing something wrong.
On Mon, Feb 17, 2014 at 8:22 AM, Brendan Jackman
<[email protected]<mailto:[email protected]>> wrote:
Hi there,
I'm developing a UEFI application that uses the EFI_TCP4_PROTOCOL. It
Configures a TCP protocol interface in passive mode and calls Accept. When a
connection is received, it opens the pre-configured protocol interface
representing that connection (to make sure I'm clear: there are now two
instances of the TCP protocol: one passive instance, on which I called Accept,
and one instance representing the established connection). It then transfers
data until it receives the CONNECTION_FIN error when the remote host closes the
connection. Finally it calls the Close function on the protocol interface
representing the connection, to close its own end of the connection.
When the connection is finished, it calls Accept again, on the original
protocol interface, to listen for another connection. This works fine - I am
able to receive multiple connections, on the same local port, one after the
other.
However, when the application exits and re-starts, the call to Configure fails
with EFI_INVALID_PARAMETER and the message "TcpConfigurePcb: Bind endpoint
failed with Invalid Parameter". Stepping through the code shows that this is
because there is still a TCP_CB in mTcpRunQue representing the TCP connection.
It has the same IP address and local port as I've passed to Configure, so the
operation fails under the assumption that someone else is already listening on
this port.
I was able to work around the issue by, when the connection is closed by the
remote host, not only calling Close on the protocol interface for the
connection, but also calling Configure with NULL as the argument. This results
in Tcp4FlushPcb being called, which removes the TCP_CB for the connection from
mRunQue. When the application exits I also call Configure with NULL on the
protocol interface representing the passive TCP listener. This is not ideal,
because it calls all the event notify functions for any submitted IO tokens.
Is this a bug, am I misunderstanding the interfaces, or somewhere in between?
Best,
Brendan
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered
in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience. Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/edk2-devel
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered
in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
