473,708 Members | 2,436 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

How do Large Scale Web Service Applications Maintain Session State?

I've been looking at two approaches for the maintenance of Session state for
a Web Service application.

One approach uses the old familiar Session object which I've used in the
past for Web applications. As far as I can see, the Session approach is
non-standard since Web Services are supposed to be agnostic with respect to
their clients. It seems that cookies are outside the Web Service standard;
therefore, such a Web Service application won't work for those clients which
are not equipped to shuttle the Session cookie back and forth.

The second approach I have researched uses the Context.Cache object, plus a
unique session ID which is shuttled back and forth as a parameter on every
method call. The unique session ID is of course, the index into the Cache
object for the retrieval of session related data. I see two drawbacks to
this approach. The first issue, is that this approach affects the parameter
signature practically every single public method in the entire application.
OK, this is perhaps a minor detail. For all I know, this may be standard
practice?

The second issue however, is that for a large scale Web Services
application, supporting thousands of concurrent sessions, the Cache memory
consumption on the server is liable to be quite large and this could be a
problem.

So I'm wondering, what is the best way to do this?

Tangentially, I'm also curious how you typically engineer your Web Service
applications. Would the server side application consist of a single ASMX
page with all application methods in a single page, or would you break your
application into separate pages? I'm thinking that from the standpoint of
team development alone, the latter method is the correct approach.

I appreciate any advice which you can offer.

Thanks!

Joseph Geretz
Feb 9 '07 #1
11 7910
Doesn't anyone use server side caching to manage session state?

If there's something fundamentally wrong with this approach, please let me
know.

Thanks!

- Joseph Geretz -

"Joseph Geretz" <jg*****@nospam .comwrote in message
news:un******** ******@TK2MSFTN GP05.phx.gbl...
I've been looking at two approaches for the maintenance of Session state
for a Web Service application.

One approach uses the old familiar Session object which I've used in the
past for Web applications. As far as I can see, the Session approach is
non-standard since Web Services are supposed to be agnostic with respect
to their clients. It seems that cookies are outside the Web Service
standard; therefore, such a Web Service application won't work for those
clients which are not equipped to shuttle the Session cookie back and
forth.

The second approach I have researched uses the Context.Cache object, plus
a unique session ID which is shuttled back and forth as a parameter on
every method call. The unique session ID is of course, the index into the
Cache object for the retrieval of session related data. I see two
drawbacks to this approach. The first issue, is that this approach affects
the parameter signature practically every single public method in the
entire application. OK, this is perhaps a minor detail. For all I know,
this may be standard practice?

The second issue however, is that for a large scale Web Services
application, supporting thousands of concurrent sessions, the Cache memory
consumption on the server is liable to be quite large and this could be a
problem.

So I'm wondering, what is the best way to do this?

Tangentially, I'm also curious how you typically engineer your Web Service
applications. Would the server side application consist of a single ASMX
page with all application methods in a single page, or would you break
your application into separate pages? I'm thinking that from the
standpoint of team development alone, the latter method is the correct
approach.

I appreciate any advice which you can offer.

Thanks!

Joseph Geretz

Feb 9 '07 #2
"Joseph Geretz" <jg*****@nospam .comwrote in message
news:Oe******** ******@TK2MSFTN GP02.phx.gbl...
Doesn't anyone use server side caching to manage session state?

If there's something fundamentally wrong with this approach, please let me
know.
Joseph,

One of the principals of SOA is to try to keep web services stateless. There
would be one large, coarse-grained operation rather than a number of
fine-grained operations which need to execute in a particular order and
maintain state between calls.

John
Feb 9 '07 #3
Joseph,

I completely understand your puzzlement... we went through the same issues
and finally decided that we will build stateful server sessions, and have
been very happy with the results. We do pass a session token as a parameter
on every call, and have only 1 asmx file with a handful of methods (public -
there are another 20 or so administrative and instrumentation ).

There is a whitepaper showing the topology, but there is much more as well.
http://www.c1s.com.au/C1prod/files/Whitepaper.pdf

Having systems deployed through web services allows clients to access via
rich [thin] clients, browsers via AJAX, etc.

Cheers,

Radek

"Joseph Geretz" <jg*****@nospam .comwrote in message
news:Oe******** ******@TK2MSFTN GP02.phx.gbl...
Doesn't anyone use server side caching to manage session state?

If there's something fundamentally wrong with this approach, please let me
know.

Thanks!

- Joseph Geretz -

"Joseph Geretz" <jg*****@nospam .comwrote in message
news:un******** ******@TK2MSFTN GP05.phx.gbl...
>I've been looking at two approaches for the maintenance of Session state
for a Web Service application.

One approach uses the old familiar Session object which I've used in the
past for Web applications. As far as I can see, the Session approach is
non-standard since Web Services are supposed to be agnostic with respect
to their clients. It seems that cookies are outside the Web Service
standard; therefore, such a Web Service application won't work for those
clients which are not equipped to shuttle the Session cookie back and
forth.

The second approach I have researched uses the Context.Cache object, plus
a unique session ID which is shuttled back and forth as a parameter on
every method call. The unique session ID is of course, the index into the
Cache object for the retrieval of session related data. I see two
drawbacks to this approach. The first issue, is that this approach
affects the parameter signature practically every single public method in
the entire application. OK, this is perhaps a minor detail. For all I
know, this may be standard practice?

The second issue however, is that for a large scale Web Services
application, supporting thousands of concurrent sessions, the Cache
memory consumption on the server is liable to be quite large and this
could be a problem.

So I'm wondering, what is the best way to do this?

Tangentially , I'm also curious how you typically engineer your Web
Service applications. Would the server side application consist of a
single ASMX page with all application methods in a single page, or would
you break your application into separate pages? I'm thinking that from
the standpoint of team development alone, the latter method is the
correct approach.

I appreciate any advice which you can offer.

Thanks!

Joseph Geretz


Feb 10 '07 #4
Radek,

Perhaps you could describe, in general, what it was about your application
which prevented you from using a stateless model?

Thanks,
John

"Radek Cerny" <ra*********@no spam.c1s.com.au wrote in message
news:uJ******** ******@TK2MSFTN GP06.phx.gbl...
Joseph,

I completely understand your puzzlement... we went through the same issues
and finally decided that we will build stateful server sessions, and have
been very happy with the results. We do pass a session token as a
parameter on every call, and have only 1 asmx file with a handful of
methods (public - there are another 20 or so administrative and
instrumentation ).

There is a whitepaper showing the topology, but there is much more as
well.
http://www.c1s.com.au/C1prod/files/Whitepaper.pdf

Having systems deployed through web services allows clients to access via
rich [thin] clients, browsers via AJAX, etc.

Cheers,

Radek

"Joseph Geretz" <jg*****@nospam .comwrote in message
news:Oe******** ******@TK2MSFTN GP02.phx.gbl...
>Doesn't anyone use server side caching to manage session state?

If there's something fundamentally wrong with this approach, please let
me know.

Thanks!

- Joseph Geretz -

"Joseph Geretz" <jg*****@nospam .comwrote in message
news:un******* *******@TK2MSFT NGP05.phx.gbl.. .
>>I've been looking at two approaches for the maintenance of Session state
for a Web Service application.

One approach uses the old familiar Session object which I've used in the
past for Web applications. As far as I can see, the Session approach is
non-standard since Web Services are supposed to be agnostic with respect
to their clients. It seems that cookies are outside the Web Service
standard; therefore, such a Web Service application won't work for those
clients which are not equipped to shuttle the Session cookie back and
forth.

The second approach I have researched uses the Context.Cache object,
plus a unique session ID which is shuttled back and forth as a parameter
on every method call. The unique session ID is of course, the index into
the Cache object for the retrieval of session related data. I see two
drawbacks to this approach. The first issue, is that this approach
affects the parameter signature practically every single public method
in the entire application. OK, this is perhaps a minor detail. For all I
know, this may be standard practice?

The second issue however, is that for a large scale Web Services
application , supporting thousands of concurrent sessions, the Cache
memory consumption on the server is liable to be quite large and this
could be a problem.

So I'm wondering, what is the best way to do this?

Tangentiall y, I'm also curious how you typically engineer your Web
Service applications. Would the server side application consist of a
single ASMX page with all application methods in a single page, or would
you break your application into separate pages? I'm thinking that from
the standpoint of team development alone, the latter method is the
correct approach.

I appreciate any advice which you can offer.

Thanks!

Joseph Geretz



Feb 10 '07 #5
Hi John,

Here's are a few specific example, in our case. First of all, our
application implements application defined authentication. To keep every
transaction absolutely stateless, this will require authentication on every
single application call. Won't it be much more efficient to allow the client
application to authenticate once against the database and then to maintain
that authenticated state for every transaction which is submitted by that
authenticated client, until the client logs off, or the time-out period
expires?

Second, and tangentially related issue, our application defines detailed
user profiles which define what a particular user can and cannot do. Again,
absolute statelessness on the Server would require us to check the database
on every single transaction to authorize the transaction. Our concept is to
cache these profiles on the server in order to increase performance.

Naturally, I agree with you that specific application classes (i.e. classes
providing direct services to application clients) on the server should not
maintain state, since this limits their usability to a single client.
However, the caching of session state on the server is a different issue and
can have tremendous benefits for performance, without compromising
scalability, if done correctly (as far as I can imagine). Our proposed
architecture would implement a stateful Web Service server application,
which is something different than stateful Web Service classes.

Again, if this is fundamentally a bad idea, I'd be interested to learn why.
But if others have implemented server side caching successfully, I am
interested to hear about that as well.

Thanks!

- Joseph Geretz -

"John Saunders" <john.saunder s at trizetto.comwro te in message
news:e9******** ******@TK2MSFTN GP02.phx.gbl...
Radek,

Perhaps you could describe, in general, what it was about your application
which prevented you from using a stateless model?

Thanks,
John

"Radek Cerny" <ra*********@no spam.c1s.com.au wrote in message
news:uJ******** ******@TK2MSFTN GP06.phx.gbl...
>Joseph,

I completely understand your puzzlement... we went through the same
issues and finally decided that we will build stateful server sessions,
and have been very happy with the results. We do pass a session token as
a parameter on every call, and have only 1 asmx file with a handful of
methods (public - there are another 20 or so administrative and
instrumentatio n).

There is a whitepaper showing the topology, but there is much more as
well.
http://www.c1s.com.au/C1prod/files/Whitepaper.pdf

Having systems deployed through web services allows clients to access via
rich [thin] clients, browsers via AJAX, etc.

Cheers,

Radek

"Joseph Geretz" <jg*****@nospam .comwrote in message
news:Oe******* *******@TK2MSFT NGP02.phx.gbl.. .
>>Doesn't anyone use server side caching to manage session state?

If there's something fundamentally wrong with this approach, please let
me know.

Thanks!

- Joseph Geretz -

"Joseph Geretz" <jg*****@nospam .comwrote in message
news:un****** ********@TK2MSF TNGP05.phx.gbl. ..
I've been looking at two approaches for the maintenance of Session
state for a Web Service application.

One approach uses the old familiar Session object which I've used in
the past for Web applications. As far as I can see, the Session
approach is non-standard since Web Services are supposed to be agnostic
with respect to their clients. It seems that cookies are outside the
Web Service standard; therefore, such a Web Service application won't
work for those clients which are not equipped to shuttle the Session
cookie back and forth.

The second approach I have researched uses the Context.Cache object,
plus a unique session ID which is shuttled back and forth as a
parameter on every method call. The unique session ID is of course, the
index into the Cache object for the retrieval of session related data.
I see two drawbacks to this approach. The first issue, is that this
approach affects the parameter signature practically every single
public method in the entire application. OK, this is perhaps a minor
detail. For all I know, this may be standard practice?

The second issue however, is that for a large scale Web Services
applicatio n, supporting thousands of concurrent sessions, the Cache
memory consumption on the server is liable to be quite large and this
could be a problem.

So I'm wondering, what is the best way to do this?

Tangentially , I'm also curious how you typically engineer your Web
Service applications. Would the server side application consist of a
single ASMX page with all application methods in a single page, or
would you break your application into separate pages? I'm thinking that
from the standpoint of team development alone, the latter method is the
correct approach.

I appreciate any advice which you can offer.

Thanks!

Joseph Geretz



Feb 11 '07 #6
"Joseph Geretz" <jg*****@nospam .comwrote in message
news:Os******** ********@TK2MSF TNGP03.phx.gbl. ..
Hi John,

Here's are a few specific example, in our case. First of all, our
application implements application defined authentication. To keep every
transaction absolutely stateless, this will require authentication on
every single application call. Won't it be much more efficient to allow
the client application to authenticate once against the database and then
to maintain that authenticated state for every transaction which is
submitted by that authenticated client, until the client logs off, or the
time-out period expires?
You can authenticate once, and have the "login" operation return an
authentication token in a SOAP header. All subsequent operations would
include the token in a SOAP header they send. I've implemented this, and
it's very simple.
Second, and tangentially related issue, our application defines detailed
user profiles which define what a particular user can and cannot do.
Again, absolute statelessness on the Server would require us to check the
database on every single transaction to authorize the transaction. Our
concept is to cache these profiles on the server in order to increase
performance.
The profiles can certainly be cached. You would use the authentication
information in the token (or referred to by the token) to determine which of
the cached profiles to use for the current operation. This is application
state, not operation state.
Naturally, I agree with you that specific application classes (i.e.
classes providing direct services to application clients) on the server
should not maintain state, since this limits their usability to a single
client. However, the caching of session state on the server is a different
issue and can have tremendous benefits for performance, without
compromising scalability, if done correctly (as far as I can imagine). Our
proposed architecture would implement a stateful Web Service server
application, which is something different than stateful Web Service
classes.
We may be using the term "stateful" to mean different things. "Stateless" to
me doesn't mean that the server doesn't maintain any state. It means that
the server doesn't depend on the saved state from previous operations in
order to process the current operation. It means that the operations aren't
constrained to execute in a particular order because the results of one
operation are required before the next can execute.

For instance, I said you can cache the profile information. But if the
profile isn't in the cache when you need to use it, you don't fail - you
load the profile into the cache.

As an example of what not to do, it would be better to create a file system
access service by creating a "ListDirect ory" operation rather than
"FindFirst" and "FindNext" operations. "FindNext" requires the server to
maintain state from the "FindFirst" and previous "FindNext" operations.
HTH,
John
Feb 11 '07 #7
Hi John,

I think we are on the same wavelength.
For instance, I said you can cache the profile information.
But if the profile isn't in the cache when you need to use it,
you don't fail - you load the profile into the cache.
Yes, this is exactly the approach we will use for data which we cache on the
server. The only question that I have is regarding the 'key' to any
user-specific information which is cached on the server. The options I've
been considering have been either to implement this in a session cookie, or
as a specific parameter. Either of these approaches has a drawback; use of
the cookie will tie the Web Service implementation to HTTP, the other
approach will require an extra parameter to be supplied with every method
call. You describe a third alternative, which is unfamiliar to me:
You can authenticate once, and have the "login" operation return an
authentication token in a SOAP header. All subsequent operations would
include the token in a SOAP header they send. I've implemented this, and
it's very simple.
I'd be interested to hear more about how this is implemented.

Once a session is established, I think I'd like to assign a GUID as a
session ID. The GUID would be the index into the cache for any session
related data which is cached on the server. I'd encapsulate the session ID
as well as the user's account credentials into the SOAP header (or cookie,
or token). Let's say the session in the server cache expires after 10
minutes of inactivity. On the next transaction I could simply use the
account credentials to re-login and recreate the cache on the server. With
this approach, I can accumulate data on the server for performance purposes
and expire data on the server to avoid unnecessary resource consumption
without impacting the user (except for the performance drop on the first
transaction following an idle timeout).

Naturally, I need some way to keep password information secure. This is true
regardless of which approach I use. Even if the password is only sent across
the wire during initial login, I need a way to ensure that this is secure.

Any advice regarding the use of SOAP headers as you suggest, and/or the
implementation of secure web services will be very much appreciated.

Thanks!

- Joe Geretz -

"John Saunders" <john.saunder s at trizetto.comwro te in message
news:em******** ******@TK2MSFTN GP04.phx.gbl...
"Joseph Geretz" <jg*****@nospam .comwrote in message
news:Os******** ********@TK2MSF TNGP03.phx.gbl. ..
>Hi John,

Here's are a few specific example, in our case. First of all, our
application implements application defined authentication. To keep every
transaction absolutely stateless, this will require authentication on
every single application call. Won't it be much more efficient to allow
the client application to authenticate once against the database and then
to maintain that authenticated state for every transaction which is
submitted by that authenticated client, until the client logs off, or the
time-out period expires?

You can authenticate once, and have the "login" operation return an
authentication token in a SOAP header. All subsequent operations would
include the token in a SOAP header they send. I've implemented this, and
it's very simple.
>Second, and tangentially related issue, our application defines detailed
user profiles which define what a particular user can and cannot do.
Again, absolute statelessness on the Server would require us to check the
database on every single transaction to authorize the transaction. Our
concept is to cache these profiles on the server in order to increase
performance.

The profiles can certainly be cached. You would use the authentication
information in the token (or referred to by the token) to determine which
of the cached profiles to use for the current operation. This is
application state, not operation state.
>Naturally, I agree with you that specific application classes (i.e.
classes providing direct services to application clients) on the server
should not maintain state, since this limits their usability to a single
client. However, the caching of session state on the server is a
different issue and can have tremendous benefits for performance, without
compromising scalability, if done correctly (as far as I can imagine).
Our proposed architecture would implement a stateful Web Service server
application, which is something different than stateful Web Service
classes.

We may be using the term "stateful" to mean different things. "Stateless"
to me doesn't mean that the server doesn't maintain any state. It means
that the server doesn't depend on the saved state from previous operations
in order to process the current operation. It means that the operations
aren't constrained to execute in a particular order because the results of
one operation are required before the next can execute.

For instance, I said you can cache the profile information. But if the
profile isn't in the cache when you need to use it, you don't fail - you
load the profile into the cache.

As an example of what not to do, it would be better to create a file
system access service by creating a "ListDirect ory" operation rather than
"FindFirst" and "FindNext" operations. "FindNext" requires the server to
maintain state from the "FindFirst" and previous "FindNext" operations.
HTH,
John


Feb 11 '07 #8
John,

basically it was the only way. We use Web Services purely as a deployment
mechanism. What we have, is in fact a full ERP/CRM/Financial system, that
grew up as abstract business objects in a 4GL. When a user "logs in" we
create a stateful server session. There are session sweepers and all sorts
of mechanisms to keep things in check, but we were able to port the entire
framework and ERP/Accounting application with minimum effort to c#. The
traffic between client & server is basically a delta exchange, so is
minimal. All business rules, persistence, formatting etc occur on the
server. We have a generic AJAX and rich Winforms client that understands
the framework delta exchange.

For us, stateful was the only way to go. Obviously, we had some hard
planning and thinking to do, and countless debates since then, but we've had
only success and no nasty side-effects from being stateful.

Cheers,

Radek
"John Saunders" <john.saunder s at trizetto.comwro te in message
news:e9******** ******@TK2MSFTN GP02.phx.gbl...
Radek,

Perhaps you could describe, in general, what it was about your application
which prevented you from using a stateless model?

Thanks,
John

"Radek Cerny" <ra*********@no spam.c1s.com.au wrote in message
news:uJ******** ******@TK2MSFTN GP06.phx.gbl...
>Joseph,

I completely understand your puzzlement... we went through the same
issues and finally decided that we will build stateful server sessions,
and have been very happy with the results. We do pass a session token as
a parameter on every call, and have only 1 asmx file with a handful of
methods (public - there are another 20 or so administrative and
instrumentatio n).

There is a whitepaper showing the topology, but there is much more as
well.
http://www.c1s.com.au/C1prod/files/Whitepaper.pdf

Having systems deployed through web services allows clients to access via
rich [thin] clients, browsers via AJAX, etc.

Cheers,

Radek

"Joseph Geretz" <jg*****@nospam .comwrote in message
news:Oe******* *******@TK2MSFT NGP02.phx.gbl.. .
>>Doesn't anyone use server side caching to manage session state?

If there's something fundamentally wrong with this approach, please let
me know.

Thanks!

- Joseph Geretz -

"Joseph Geretz" <jg*****@nospam .comwrote in message
news:un****** ********@TK2MSF TNGP05.phx.gbl. ..
I've been looking at two approaches for the maintenance of Session
state for a Web Service application.

One approach uses the old familiar Session object which I've used in
the past for Web applications. As far as I can see, the Session
approach is non-standard since Web Services are supposed to be agnostic
with respect to their clients. It seems that cookies are outside the
Web Service standard; therefore, such a Web Service application won't
work for those clients which are not equipped to shuttle the Session
cookie back and forth.

The second approach I have researched uses the Context.Cache object,
plus a unique session ID which is shuttled back and forth as a
parameter on every method call. The unique session ID is of course, the
index into the Cache object for the retrieval of session related data.
I see two drawbacks to this approach. The first issue, is that this
approach affects the parameter signature practically every single
public method in the entire application. OK, this is perhaps a minor
detail. For all I know, this may be standard practice?

The second issue however, is that for a large scale Web Services
applicatio n, supporting thousands of concurrent sessions, the Cache
memory consumption on the server is liable to be quite large and this
could be a problem.

So I'm wondering, what is the best way to do this?

Tangentially , I'm also curious how you typically engineer your Web
Service applications. Would the server side application consist of a
single ASMX page with all application methods in a single page, or
would you break your application into separate pages? I'm thinking that
from the standpoint of team development alone, the latter method is the
correct approach.

I appreciate any advice which you can offer.

Thanks!

Joseph Geretz



Feb 11 '07 #9
"Joseph Geretz" <jg*****@nospam .comwrote in message
news:uG******** *****@TK2MSFTNG P05.phx.gbl...
Hi John,
....
Any advice regarding the use of SOAP headers as you suggest, and/or the
implementation of secure web services will be very much appreciated.
SOAP headers are pretty easy to use. There's a good example in the MSDN
documentation at
http://msdn.microsoft.com/library/de...ClassTopic.asp.

John
Feb 11 '07 #10

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

Similar topics

0
2276
by: Constandinos Mavromoustakis | last post by:
CFP: CLADE 2004-Challenges of Large Applications in Distributed Environments ------------------------------------------------- PhD student - Dept.Informatics at Aristotle University of Thessaloniki URL-> http://agent.csd.auth.gr/~cmavrom -------------------------------------------------- -------------------------CLADE 2004--------------------------- Challenges of Large Applications in Distributed Environments June 7th, 2004, Honolulu,...
9
2420
by: limor | last post by:
Hi, I am considering using Python in a new testing tool application we intend to build for out product. I must get references before starting develope in this language , since although lots of good things are said about this language , I still have my doubts how can it compete with languages like C++ and Java. I have found te sytax and some features if the language not as problematic in maintenance prospective (although I keep reading...
36
6390
by: Andrea Griffini | last post by:
I did it. I proposed python as the main language for our next CAD/CAM software because I think that it has all the potential needed for it. I'm not sure yet if the decision will get through, but something I'll need in this case is some experience-based set of rules about how to use python in this context. For example... is defining readonly attributes in classes worth the hassle ? Does duck-typing scale well in complex
7
10320
by: Lalit | last post by:
Hi Friends, I have developed a Windows service. Now i need icon for this service in systray and context menu fo this icon. Can i do this? With regards, Lalit
2
2183
by: mg | last post by:
I'm trying to store session state in a Windows Service. I start the ASP.NET State Service and modify the Web.Config file to include <sessionState mode="StateServer" stateConnectionString="tcpip=127.0.0.1:42424" timeout="20" />
1
1265
by: DwC | last post by:
Hey All, I have a web service that maintains it's own state so once the user has successfully called the Login method a logged in flag is set in session. Each method checks that the user is a valid user and has logged in before returning anything.
17
6438
by: UJ | last post by:
Is there any way for a windows service to start a windows program ? I have a service that will need to restart a windows app if it needs to. TIA - Jeff.
2
6893
by: deko | last post by:
When to use a privileged user thread rather than a windows service? That's the question raised in a previous post . It was suggested that if the service needs to interact with a WinForms app (which is the UI used to adjust the actions taken by, and the schedule of the service), then a privileged user thread should be used in the UI - no service required. But... "A windows service enables the creation of long-running executable
11
3653
by: Glenn | last post by:
Hi I've been experimenting with managing state using the Session object. I've created a simple WS with a couple of methods, one which sets a string value, another that retrieves it. Each method has the WebMethodAttribute.EnableSession set to true. When I run the test page the session is maintained. However, using a console application, in between setting the string value and attempting to
0
8697
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,...
1
9060
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
9001
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
1
6615
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
5939
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
4454
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
4712
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
3151
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
2096
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.