473,848 Members | 1,538 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

throwing dtors...

Is it every appropriate to throw in a dtor? I am thinking about a simple
example of a wrapper around a POSIX file...
_______________ _______________ _______________ _______________ ____________
class file {
FILE* m_handle;

public:
// [...];

~file() /* throw() */ {
int const status fclose(m_handle );
if (status) {
/* shi% hit the fan:
http://www.opengroup.org/onlinepubs/...sh/fclose.html
/*

// [what now?]
}
}
};
_______________ _______________ _______________ _______________ ____________
How to properly handle `EAGAIN' in dtor? Well, what about any error for that
matter? I am a C programmer and only code C++ for fun, and some in-house
projects. If I were really going to create C++ application and release it
into the wild, well, how would you advise me to handle the case above? I am
interested in how throwing in a dtor effects dynamic destruction... Would
something like the following be legal?

<pseudo code!!!!>
_______________ _______________ _______________ _______________ ___
struct throw_from_dtor {
int const m_status;

public:
throw_from_dtor (int const status)
m_status(status ) {}

int get_status() const { return m_status; }
};

class file {
FILE* m_handle;

public:
// [ctor];

~file() {
int const status = fclose(m_handle );
if (status) {
throw throw_from_dtor (status);
}
}
};
int main() {
file* f = new file();
try {
delete f;
} catch(throw_fro m_dtor const& e) {
// handle error from `e.get_status() '
delete f;
}
return 0;
}
_______________ _______________ _______________ _______________ ___
?
or what about using smart pointer...

int main() {
std::auto_ptr<f ilef;
try {
f.reset(new file());
} catch(throw_fro m_dtor const& e) {
// handle error from `e.get_status() '
}
}

?


Please keep in mind that refusing to not handle an error from `fclose' could
resule is HORRIBLE things down the road... Think massive data lost...
Perhaps __permanent__ data-! OUCH!!!

;^/

Oct 2 '08 #1
21 1736

"Chris M. Thomasson" <no@spam.invali dwrote in message
news:k4******** **********@news fe06.iad...
Is it every appropriate to throw in a dtor? I am thinking about a simple
example of a wrapper around a POSIX file...
_______________ _______________ _______________ _______________ ____________
[...]
_______________ _______________ _______________ _______________ ____________
How to properly handle `EAGAIN' in dtor? Well, what about any error for
that matter? I am a C programmer and only code C++ for fun, and some
in-house projects. If I were really going to create C++ application and
release it into the wild, well, how would you advise me to handle the case
above? I am interested in how throwing in a dtor effects dynamic
destruction... Would something like the following be legal?

<pseudo code!!!!>
_______________ _______________ _______________ _______________ ___
struct throw_from_dtor {
int const m_status;

public:
throw_from_dtor (int const status)
m_status(status ) {}

int get_status() const { return m_status; }
};

class file {
FILE* m_handle;

public:
// [ctor];

~file() {
int const status = fclose(m_handle );
if (status) {
throw throw_from_dtor (status);
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^

// ummmm! well, stupid me forgot to store `errno' into the
exception!!!!!!

throw throw_from_dtor (errno);

// sorry about the non-sense! ;^(...
}
}
};

int main() {
file* f = new file();
try {
delete f;
} catch(throw_fro m_dtor const& e) {
// handle error from `e.get_status() '
delete f;
}
return 0;
}
_______________ _______________ _______________ _______________ ___
?
or what about using smart pointer...

int main() {
std::auto_ptr<f ilef;
try {
f.reset(new file());
} catch(throw_fro m_dtor const& e) {
// handle error from `e.get_status() '
}
}

?


Please keep in mind that refusing to not handle an error from `fclose'
could resule is HORRIBLE things down the road... Think massive data
lost... Perhaps __permanent__ data-! OUCH!!!

;^/
Oct 2 '08 #2
"Chris M. Thomasson" <no@spam.invali dwrote in message
news:k4******** **********@news fe06.iad...
Is it every appropriate to throw in a dtor? I am thinking about a simple
example of a wrapper around a POSIX file...
_______________ _______________ _______________ _______________ ____________
[...]
_______________ _______________ _______________ _______________ ____________
[...]
how would you advise me to handle the case above? I am interested in how
throwing in a dtor effects dynamic destruction... Would something like the
following be legal?
[...]

I am doing some experimenting, and found that throwing from a dtor
apparently leaves the object fully intact wrt the memory that makes it up so
that proper disaster cleanup can indeed be performed... For example, the
following program goes into infinite loop:
_______________ _______________ _______________ _______________ __________
#include <cstdio>

struct throw_on_dtor {};

class foo {
public:
~foo() {
throw throw_on_dtor() ;
}
};

int main(void) {
foo* f = new foo();
retry:
try {
delete f;
} catch (throw_on_dtor const& e) {
std::puts("thro w_on_dtor caught!");
goto retry;
}
return 0;
}

_______________ _______________ _______________ _______________ __________


So, AFAICT, throwing from a dtor will complicate some odd complications.
However, they can be worked out for sure. This fact that a dtor can throw
will need to be CLEARY documented indeed. The above highly crude technique
can be used to solve the fact when a file close is interrupted by a signal
(e.g., `EINTR'). It can also be used to handle `EAGAIN'... Although, it
seems eaiser to use placement new when your dealing with a class that can
throw from its dtor, so that the catch block can actually free memory
without running the dtor again like delete does... Something like:

_______________ _______________ _______________ _______________ __________
#include <cstdio>
#include <cstdlib>
#include <new>

struct throw_on_dtor {};

class foo {
public:
~foo() {
throw throw_on_dtor() ;
}
};

int main(void) {
foo* f = new (std::malloc(si zeof(*f))) foo();
if (f) {
retry:
try {
f->~foo();
std::free(f);
} catch (throw_on_dtor const& e) {
std::puts("thro w_on_dtor caught! Handling Error...");
std::free(f);
}
}
return 0;
}
_______________ _______________ _______________ _______________ __________

Humm... The placement new soultion looks like a good match for throwing
dtors indeed!

Also, a class which throws from dtors could contain a dtor counter and/or
flag to detect how many times, if any, the dtor has been invoked; something
like:

class foo {
unsigned m_dtor_invoke; // = 0
bool m_dtor_throw; // = false;
public:
~foo() {
++m_dtor_invoke ;
if (! m_dtor_throw) {
m_dtor_throw = true;
throw throw_on_dtor() ;
}
}
};

Any thoughts? BTW, try not to flame me too harshly! I am trying to avoid the
user explicitly calling a close function... Or, is that a great idea wrt
dealing with any class that has a dtor which calls an API that can fail
_AND_ such failure indicates something important?
;^(...

Oct 2 '08 #3

"Chris M. Thomasson" <no@spam.invali dwrote in message
news:ao******** **********@news fe06.iad...
"Chris M. Thomasson" <no@spam.invali dwrote in message
news:k4******** **********@news fe06.iad...
>Is it every appropriate to throw in a dtor? I am thinking about a simple
example of a wrapper around a POSIX file...
______________ _______________ _______________ _______________ _____________
[...]
>______________ _______________ _______________ _______________ _____________
[...]
>how would you advise me to handle the case above? I am interested in how
throwing in a dtor effects dynamic destruction... Would something like
the following be legal?
[...]

I am doing some experimenting, and found that throwing from a dtor
apparently leaves the object fully intact wrt the memory that makes it up
so that proper disaster cleanup can indeed be performed... For example,
the following program goes into infinite loop:
_______________ _______________ _______________ _______________ __________
#include <cstdio>

struct throw_on_dtor {};

class foo {
public:
~foo() {
throw throw_on_dtor() ;
}
};

int main(void) {
foo* f = new foo();
retry:
try {
delete f;
} catch (throw_on_dtor const& e) {
std::puts("thro w_on_dtor caught!");
goto retry;
}
return 0;
}

_______________ _______________ _______________ _______________ __________


So, AFAICT, throwing from a dtor will complicate some odd complications.
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^

let me rephrase:

So, AFAICT, throwing from a dtor will _create_ some odd complications.. .


Humm... I am now thinking that instead of throwing from dtor, all error
handling should be preformed within dtor... However, what if user wants to
be informed of any failure case within dtor? Should I provide a simple
callback function to inform user of such condition? Something like:
_______________ _______________ _______________ ______________
class file {
FILE* m_handle;
bool (*m_fp_on_dtor_ error) (file&, int);

public:
foo(fp_on_dtor_ error fp = NULL)
: m_fp_on_dtor_er ror(fp) {
[...]
};

~foo() {
retry:
if (! fclose(m_handle )) {
if (m_fp_on_dtor_e rror) {
if (m_fp_on_dtor_e rror(*this, errno)) {
goto retry;
}
}
}
}
};
_______________ _______________ _______________ ______________


Humm... I need ADVISE!

;^o

Oct 2 '08 #4
Chris M. Thomasson wrote:
Is it every appropriate to throw in a dtor? I am thinking about a simple
example of a wrapper around a POSIX file...
Take a look here:
http://www.parashift.com/c++-faq-lit...html#faq-11.13
_______________ _______________ _______________ _______________ ____________
class file {
FILE* m_handle;

public:
// [...];

~file() /* throw() */ {
int const status fclose(m_handle );
if (status) {
/* shi% hit the fan:
http://www.opengroup.org/onlinepubs/...sh/fclose.html
/*

// [what now?]
}
}
};
_______________ _______________ _______________ _______________ ____________
How to properly handle `EAGAIN' in dtor? Well, what about any error for
that matter? I am a C programmer and only code C++ for fun, and some
in-house projects. If I were really going to create C++ application and
release it into the wild, well, how would you advise me to handle the
case above? I am interested in how throwing in a dtor effects dynamic
destruction... Would something like the following be legal?
How would you handle it in C?
>

<pseudo code!!!!>
_______________ _______________ _______________ _______________ ___
struct throw_from_dtor {
int const m_status;

public:
throw_from_dtor (int const status)
m_status(status ) {}

int get_status() const { return m_status; }
};

class file {
FILE* m_handle;

public:
// [ctor];

~file() {
int const status = fclose(m_handle );
if (status) {
throw throw_from_dtor (status);
}
}
};
int main() {
file* f = new file();
try {
delete f;
} catch(throw_fro m_dtor const& e) {
// handle error from `e.get_status() '
delete f;
}
return 0;
}
_______________ _______________ _______________ _______________ ___
?
or what about using smart pointer...

int main() {
std::auto_ptr<f ilef;
try {
f.reset(new file());
} catch(throw_fro m_dtor const& e) {
// handle error from `e.get_status() '
}
}

?
These two mains are almost the same (at least they are doing the same thing.
>
Please keep in mind that refusing to not handle an error from `fclose'
could resule is HORRIBLE things down the road... Think massive data
lost... Perhaps __permanent__ data-! OUCH!!!
What can you do when fclose fails?
Oct 2 '08 #5
"anon" <an**@no.invali dwrote in message
news:gc******** **@news01.versa tel.de...
Chris M. Thomasson wrote:
>Is it every appropriate to throw in a dtor? I am thinking about a simple
example of a wrapper around a POSIX file...

Take a look here:
http://www.parashift.com/c++-faq-lit...html#faq-11.13
Okay; I will give it a look.

[...]
How would you handle it in C?
[...]
What can you do when fclose fails?
Well, it depends on the error:

http://www.opengroup.org/onlinepubs/...sh/fclose.html

For instance, fclose can get interrupted by a signal. In this case, you need
to reissue the operation; e.g:
_______________ _______________ _______________ _______________ __
struct file {
FILE* handle;
};

int file_close(
struct file* const this
) {
int status;
do {
status = fclose(this->handle);
} while (status == EOF && errno == EINTR);
return status;
}
_______________ _______________ _______________ _______________ __


Or, what if it returns `EAGAIN', well, this certainly needs to be handled.
However, it would be better to let the application to handle this, not do it
implicitly within the `file_close()' function. There are many ways to handle
this. That's not the problem. The problem is when a retarded program does
not handle it! IHO, any program that does not explicitly handle errors from
`fclose()' is severely broken and VERY dangerous. Let me give you a
example... Imagine a C++ wrapper around a C FILE... Fine. Imagine the dtor
looks like this:

class file {
FILE* m_handle;

public:
~file() throw() {
fclose(m_handle );
}
};

Fine... Now, a user needs to copy a file to a disk, and destroy the
original. Okay. It creates two file objects (e.g., src and dest:)

{
file src(...);
file dest(...);

// Then it performs the copy operation:

[copy src to dest]
}

Now the code-block goes out of scope, and no exceptions were thrown during
the copy process, HOWEVER, the call to `fclose()' in the dest object
failed!!!! Well, the user thinks everything is fine because the completely
retarded ignorant moron file object did not report the fuc%ing error! So the
user operates in ignorance and happily destroys the original file thinking
that the file was COMPLETELY copied onto the disk! WRONG! The file was
partially copied because `fclose()' failed to do its thing and properly
flush the buffers, or whatever... Now, the missing file data is LOST
__forever__! OUCH!!!
This is why its ESSENTIAL to report and handle errors from `fclose()'... If
`fclose()' fails, you can't be so sure that the file is 100% coherent...
Any thoughts?

Oct 2 '08 #6
"anon" <an**@no.invali dwrote in message
news:gc******** **@news01.versa tel.de...
Chris M. Thomasson wrote:
>Is it every appropriate to throw in a dtor? I am thinking about a simple
example of a wrapper around a POSIX file...

Take a look here:
http://www.parashift.com/c++-faq-lit...html#faq-11.13
[...]

Well, AFAICT, it seems like C++ destructors are really not all that good for
gracefully handling critical shutdown operations in dtors, such as
`fclose()'. Where am I going wrong? It seems like the only way to avoid
throwing from a dtor would be doing something along the lines of:
// example on how to handle EINTR or perhaps even EAGAIN
_______________ _______________ _______________ _______________ __________
class file {
FILE* m_handle;

// returns true to retry; or false to continue...
bool (*m_fp_on_fclos e_dtor) (int);

public:
file(bool (*fp_on_fclose_ dtor) (int) = NULL, ...)
: m_fp_on_fclose_ dtor(fp_on_fclo se_dtor) {
// [...];
}

~file() throw() {
while (fclose(m_handl e) == EOF) {
if (m_fp_on_fclose _dtor && !
m_fp_on_fclose_ dtor(errno)) {
break;
}
}
}
};


static bool on_fclose_dtor( int status) {
switch (status) {
case EINTR:
return true;

case EAGAIN:
sleep(1);
return true;

default:
std::terminate( );
}
}
int main() {
{
file f(on_fclose_dto r, ...);
// [...];
}
return 0;
}
_______________ _______________ _______________ _______________ __________

Now, if a signal is thrown, or if the operation would block, the operation
will at least try to gracefully complete. All other errors KILL the program
dead... Sounds good to me.


However, this looks like a horrible hack. There has to be a MUCH between way
indeed!

:^o

Oct 2 '08 #7
"Chris M. Thomasson" <no@spam.invali dkirjutas:
Is it every appropriate to throw in a dtor? I am thinking about a
simple example of a wrapper around a POSIX file...
_______________ _______________ _______________ _______________ ___________
_ class file {
FILE* m_handle;

public:
// [...];

~file() /* throw() */ {
int const status fclose(m_handle );
if (status) {
/* shi% hit the fan:
http://www.opengroup.org/onlinepubs/...sh/fclose.html
/*

// [what now?]
}
}
};
_______________ _______________ _______________ _______________ ___________
_
How to properly handle `EAGAIN' in dtor? Well, what about any error
for that matter? I am a C programmer and only code C++ for fun, and
some in-house projects. If I were really going to create C++
application and release it into the wild, well, how would you advise
me to handle the case above? I am interested in how throwing in a dtor
effects dynamic destruction... Would something like the following be
legal?
Throwing from a dtor is not really advisable in C++. It can easily lead
to duplicate throws during stack unwinding, and calling terminate() as
the result.

The C++ RAII model is built up on the assumption that releasing the
resource always succeeds (or its failure can be ignored by upper levels).
If this is not the case, then the application logic becomes very complex
immediately, essentially you are back in C again.

In any case, I would suggest to move any activity which can fail out of
the destructor, into a separate member function which has to be called
explicitly before destroying of the object, possibly from inside a try-
catch block dealing with errors.

In regard of this example, for most applications, fclose() failing
indicates that the disk is full. What can you do about this? Try to
delete some random other files from the disk? For most applications I
believe a proper behavior would be to try to log the error somewhere,
then either continue or abort, depending on the application type.

If the file integrity is of the most importance, e.g. in case of a
database program, this has to be managed explicitly anyway by storing
something like transaction completion markers in the file itself, or
whatever. I bet this is not trivial.

hth
Paavo


Oct 2 '08 #8
Chris M. Thomasson wrote:
"anon" <an**@no.invali dwrote in message
news:gc******** **@news01.versa tel.de...
>Chris M. Thomasson wrote:
>>Is it every appropriate to throw in a dtor? I am thinking about a
simple example of a wrapper around a POSIX file...

Take a look here:
http://www.parashift.com/c++-faq-lit...html#faq-11.13
[...]

Well, AFAICT, it seems like C++ destructors are really not all that good
for gracefully handling critical shutdown operations in dtors, such as
`fclose()'. Where am I going wrong? It seems like the only way to avoid
throwing from a dtor would be doing something along the lines of:
Destructors have to cleanup its objects, and they should (must) not fail.
>
// example on how to handle EINTR or perhaps even EAGAIN
_______________ _______________ _______________ _______________ __________
class file {
FILE* m_handle;

// returns true to retry; or false to continue...
bool (*m_fp_on_fclos e_dtor) (int);

public:
file(bool (*fp_on_fclose_ dtor) (int) = NULL, ...)
: m_fp_on_fclose_ dtor(fp_on_fclo se_dtor) {
// [...];
}

~file() throw() {
while (fclose(m_handl e) == EOF) {
if (m_fp_on_fclose _dtor && !
m_fp_on_fclose_ dtor(errno)) {
break;
}
}
}
};

IMO This would be better:

class file {
FILE* m_handle;

public:
file()
{
// [...];
}

~file()
{
try
{
close_file();
}
// catch other exceptions
catch(...)
{
// log the error
}
}

void close_file()
{
// do whatever you can to close the file
// throw an exception in a case of an error
}

};

int main()
{
try
{
file obj;
// do stuff
obj.close_file( );
}
catch(...)
{
// log error
// try to repair the damage
}
}
>
Now, if a signal is thrown, or if the operation would block, the
operation will at least try to gracefully complete. All other errors
KILL the program dead... Sounds good to me.

With all other errors, your file will not be closed, and you have a
terminated program. Not very elegant solution ;)
Oct 2 '08 #9
On Oct 2, 5:25 am, "Chris M. Thomasson" <n...@spam.inva lidwrote:
Is it every appropriate to throw in a dtor?
Sure. There are special cases where the only reason to have a
destructor is for it to throw.

All such cases are, however, special cases, and objects of those
types should only exist in special contexts (typically, as
temporaries in a single expression).
I am thinking about a simple example of a wrapper around a
POSIX file...
That one definitly shouldn't throw.
_______________ _______________ _______________ _______________ ____________
class file {
FILE* m_handle;
public:
// [...];
~file() /* throw() */ {
int const status fclose(m_handle );
if (status) {
/* shi% hit the fan:
http://www.opengroup.org/onlinepubs/...sh/fclose.html
/*
// [what now?]
}
}
};
_______________ _______________ _______________ _______________ ____________
If you get to the destructor and the file hasn't been closed,
it's an error. It should only happen in two cases: your
unwinding the stack as a result of another error (which will
result in the generated file being deleted, or at least marked
as invalid), or there is an error elsewhere in the code (which
should result in an assertion failure).
How to properly handle `EAGAIN' in dtor? Well, what about any
error for that matter? I am a C programmer and only code C++
for fun, and some in-house projects. If I were really going to
create C++ application and release it into the wild, well, how
would you advise me to handle the case above?
Require an explicit close by the user, before the object is
destructed, and return a return code from that function.

FWIW: most of my file output is through a file wrapper class
whose destructor deletes the file if it is called before the
file is "committed" ; it also has an option for linking several
such wrappers, so that all of the files will be deleted unless
all have been successfully "committed" . (Also, my shutdown
routines flush cout, and generate an error if that fails.)

[...]
Please keep in mind that refusing to not handle an error from
`fclose' could resule is HORRIBLE things down the road...
Obviously. And since the error must be handled, you never count
on the destructor for the close. (In the normal case---it's
fine if you're cleaning up after another error, and are going to
delete the file anyway as a result of the other error.)

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Oct 2 '08 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

8
2872
by: Gerhard Wolfstieg | last post by:
The following situation: class A0 { static A0 *a0; // something like this to publish the pointer public: A0() { a0 = this; } virtual ~A0(){}
2
1518
by: SK | last post by:
What is the purpose of throwing exceptions in catch block. Bcos the exception is already thrown only, it is coming to the catch block.What is the purpose of throwing it again then!!!.....Help
5
4692
by: Mark Oueis | last post by:
I've been struggling with this question for a while. What is better design? To design functions to return error codes when an error occures, or to have them throw exceptions. If you chose the former, i have a few questions that need to be answered. 1) What about functions that need to return a value regardless of the error. How can they also return an error code unless the function has "output" parameters. This seems messy and...
6
2254
by: BigMan | last post by:
Is it safe to call nonvirtual member functions from ctors and dtors? What about virtual ones?
21
4458
by: mihai | last post by:
People say that is a bad technique to throw exception from constructors; and that the solution would be to create a function _create_ to initialize an object. What about copy constructors? How can we avoid throwing exceptions? If we already have an abject witch was initialized wit _create_ we will be forced to call create in copy constructor and to throw exceptions from it. Have a nice day,
1
1672
by: Farooq Khan | last post by:
i'm writing a class library having following code snippet. i want this class to report an error (by throwing an Exception) to the application using this class library. the problem is that within that try block there are several exceptions that this class itself needs to handle (interrnally). now when the exception, UserAlreadyRegistered, is thrown the class' catch block (within library) catches it and no exception is thrown to the...
40
13553
by: Kevin Yu | last post by:
is it a bad programming design to throw exception in the try block then catch it??
0
9735
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
10996
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
10658
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
0
9497
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
0
7062
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
5730
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
5915
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
4541
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
3
3171
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.