I have been hearing this word "Client Side" whenever I read book or while listening to my trainer when he teaches Object oriented programming concepts. What does exactly it mean? Can anybody help me providing an answer with example?
Answer would be appreciated.
"Client side" just means "from the perspective of the user of the object", i.e. the people who are going to be using the interface, as opposed to the implementors.
Client-server describes an application architecture in which the client requests an action or service from the provider of service, the server. For e.g. browser is the client of a web server. Now the client and server can be co-located within the same process or within the same computer or they can be running on different computers.
Client side vs. server side:
Client side programs/applications are typically "regular" computer programs, like a web browser, a game, a text editor, etc. In network programming, and that's more often, it refers to one of the peer computer programs that communicate with the server.
The counterpart of client side is server side; server applications are typically not directly utilized by the users, and due to this fact, some special considerations shall be made while making server(-side) applications. For example, there are typically some differences in programming languages, such as JavaScript and PHP.
Related
WebRTC signalling is driving me crazy. My use-case is quite simple: a bidirectional audio intercom between a kiosk and to a control room webapp. Both computers are on the same network. Neither has internet access, all machines have known static IPs.
Everything I read wants me to use STUN/TURN/ICE servers. The acronyms for this is endless, contributing to my migraine but if this were a standard application, I'd just open a port, tell the other client about it (I can do this via the webapp if I need to) and have the other connect.
Can I do this with WebRTC? Without running a dozen signalling servers?
For the sake of examples, how would you connect a browser running on 192.168.0.101 to one running on 192.168.0.102?
STUN/TURN is different from signaling.
STUN/TURN in WebRTC are used to gather ICE candidates. Signaling is used to transmit between these two PCs the session description (offer and answer).
You can use free STUN server (like stun.l.google.com or stun.services.mozilla.org). There are also free TURN servers, but not too many (these are resource expensive). One is numb.vigenie.ca.
Now there's no signaling server, because these are custom and can be done in many ways. Here's an article that I wrote. I ended up using Stomp now on client side and Spring on server side.
I guess you can tamper with SDP and inject the ICE candidates statically, but you'll still need to exchange SDP (and that's dinamycally generated each session) between these two PCs somehow. Even though, taking into account that the configuration will not change, I guess you can exchange it once (through the means of copy-paste :) ), stored it somewhere and use it every time.
If your end-points have static IPs then you can ignore STUN, TURN and ICE, which are just power-tools to drill holes in firewalls. Most people aren't that lucky.
Due to how WebRTC is structured, end-points do need a way to exchange call setup information (SDP) like media ports and key information ahead of time. How you get that information from A to B and back to A, is entirely up to you ("signaling server" is just a fancy word for this), but most people use something like a web socket server, the tic-tac-toe of client-initiated communication.
I think the simplest way to make this work on a private network without an internet connection is to install a basic web socket server on one of the machines.
As an example I recommend the very simple https://github.com/emannion/webrtc-web-socket which worked on my private network without an internet connection.
Follow the instructions to install the web socket server on e.g. 192.168.1.101, then have both end-points connect to 192.168.0.101:1337 with Chrome or Firefox. Share camera on both ends in the basic demo web UI, and hit Connect and you should be good to go.
If you need to do this entirely without any server, then this answer to a related question at least highlights the information you'd need to send across (in a cut'n'paste demo).
My previous question was closed so I will be more specific.
I need to create an application, desktop one written in C#, that will ask for user credentials and after verification opens the GUI allowing to work with DB (black box for users).
It should be used from everywhere, not LAN or SQL domain. I assume I would need to do the following:
Create a client and a server applications that will deal with authentification. That would mean a lot of socketing stuff..
Once the user is verified, the client queries would be sent to database (client->server->DB).
The server would need to send the DB data sets back to the client.
As you can see, this is just my guess but I have no idea whether its too complicated or completely wrong. The main thing is that it must be desktop app (not web based one) and accessible from everywhere.
I am interested in main points how to design the system and will be extremely grateful for that.
You can use a certificate server for authentication..like Apache's mod_ssl
I'm writing a server that needs to serve many clients. The traffic is NOT http (but rather some proprietary protocol on top of TCP). I'm not very familiar with commercial web servers such as IIS and Apache. Can anyone tell me if it's possible to write some sort of "extension" to run on top of one of these platforms so that I don't have to write the logic for the sockets? Or perhaps there is another way (not IIS or Apache) of doing it which is better?
My server is generally going to behave as a web service (gets request, queries db, sends response) however there is one scenario in which it stays connected to the client socket and sends updates at a given interval on that socket.
It seems reasonable for it to be a way to do this in a way that I'd only have to write my logic without the general logic of a server. Any ideas?
Thanks!
Good question, and its also good too look to leverage an existing web server - you get scalability and stability, effectively for free.
I've never done this myself, but it should be totally possible in IIS (i recommend v7+ for this, makes it easier).
You can set up a new web site through the administration tool, and assign it a port to listen on - this bit is pretty straight forward. You should set its Binding Type to net.tcp (this is a dropdown in the dialog to add a new website, you can't miss it).
You can then use either modules or handlers to implement the rest of your custom functionality. This article Developing IIS 7.0 Modules and Handlers with the .NET Framework is a good intro to the subject. Most of the doco out there about writing custom handlers and modules is focussed on the HTTP protocol, but there are some snippets floating around for TCP and/or net.tcp (because IIS and Apache are web servers, and web is synonymous with http). Another resource that may be useful is this: Configure Request-Processing for a Web Server (IIS 7)
Alternatively, you may consider changing your approach and do it as a net.tcp WCF service, with this you get the benefits of using IIS, the flexibility of choosing the protocol (can be statically configured, doesn't need to be compiled in), and you don't have to write handlers or modules.
I am faced with a WCF security scenario that isn't particularly well documented online.
I am developing a product licensing service in WCF that will be deployed along with our software (i.e. the service is running on the same PC as the client). This licensing service will be responsible for a number of things related to controlling use of our software and connecting to our remote licensing server for updates, revocations etc. Consequently it's not the kind of service I want spoofed, and I don't really want spoof clients communicating with it either.
As it's running on the same PC as the client can anyone suggest a security policy for this scenario? I'm particularly interested in authentication as most of the other security principles are straightforward. I'm reluctant to get into certificates if I can help it but as mutual authentication is a priority I'm beginning to think I may need to implement a custom 'challenge/verify' scheme between the service and client.
Any ideas? Thanks for reading.
Chris.
My suggestion is that no matter how much effort you put into that, there will be an attack vector that makes all of your effort null and void. One option is to use ILMerge to provide a single dll for your entire application, and store it encrypted on disk and create a loader that hits your service passing in the registration information. On your side, the service will validate the customer information and send back a decryption key. The loader would use the decryption key to decrypt the DLL in memory and load it dynamically.
The shortcoming of this approach is that a determined cracker could debug your application and when the DLL is decrypted, write the unencrypted stream to disk. Your only means of retribution would be to place some kind of marker on the DLL so that you can identify who was responsible for breaking your copy protection and bring legal action if it's found open on the Internet.
As long as you're deploying this software to the client, then you cannot store any kind of key inside it without risking compromise. Even if you use certificates, you cannot hide them from the client while still making them visible to your application. And if you embed the key in the assembly itself then someone will just pop it open using Reflector.
Assuming you don't care about outright cracking (i.e. patching the assembly's code to simply bypass the license checks), then there's one and only one correct way to implement this type of security and that is to mimic the way a PKI works, by using a remote server exclusively.
In a PKI, when a server needs to validate a client via a certificate, it checks that certificate against the certificate authority's CRL. If the CRL reports that the certificate is revoked then it refuses access. If the CRL cannot be contacted then the certificate is considered invalid.
If you want to implement this scenario then you need 3 logical services but not in your current configuration. What you need is a remote licensing server, a client, and an application server. The application server can, theoretically, reside on the client, but the key aspect of this app server is that it performs license checks against the remote licensing service and handles all of the important application logic. That way, "spoofing" the server becomes an almost impossible task because a casual cracker would have to reverse-engineer the entire application in the process.
This is significantly less safe than making the application server a remote server, and may not offer many advantages over simply embedding remote security checks in the client itself and scrapping the local app/licensing server completely. But if you are determined to take this 3-tier approach then the aforementioned architecture would be the way to go.
Again, this is assuming that you aren't worried about "direct" cracking. If you are, then you'll have to read up on techniques specific to that particular attack vector, and understand that none of them are foolproof; they can only slow an attacker down, never stop him completely.
In my office building we have laptops on multiple floors all running a WCF Service. When WCF services communicate with each other, will a message for an out-of-range device automatically reach it by multi-hopping? Does WCF/the WLAN device driver handle this? Or do I have to detect if a device is not contactable/out-of-range and implement hopping in my own service?
As long as you have a connection from your WCF client to the service - yes, all avenues will be used. You shouldn't have to concern yourself with things like what network path your messages take - the network just has to be present and stable for the duration of a call ;-)
There's nothing in WCF to deal with this, really - this should be handled way lower in the network stack, by the driver or the OS.
Short answer
With WCF can do either or both of these:
Rely on an underlying protocol like IP to handle roaming
Use custom channel code that handles retries, roaming, etc the way you want it
No special mechanism for enhancing roaming is provided in the WCF classes Microsoft provides, but the framework itself is easily capable of supporting this seamlessly if you write or find a channel implementation to do this.
Full answer
WCF is not an on-the-wire protocol. It is a framework that allows you to communicate using a wide variety of protocols and network stacks. This allows you to use the same client and server code whether you are using HTTPS, raw TCP, named pipes, or any other protocol.
WCF ships with many channels in the box, and you can add your own. For example if you want to communicate over BlueTooth or IRDA, just create a new channel that talks these protocols and you can use your WCF services over it. These channels can also be found online or purchased from vendors.
Most networking today is done using the IP protocol, and if you are using WCF to communicate between desktop machines you will probably be using some protocol(s) on top of IP, for example TCP or HTTP. In this case, IP's normal routing rules will be used, so if the two machines can exchane IP packets you can communicate using WCF.
So if your WiFi access points allow seamless roaming you will be able to tap into that functionality using WCF.
If your WiFi routing doesn't have seamless roaming, you will have to do some extra work if you want to maintain a connection during roaming. Specifically you will need to create a channel that will respond to a closed connetion by re-resolving the server nane and retrying the request. Of course you will have to use DNS or another protocol so the server can update its registration as its IP address changes.
WCF is flexible enough to allow you to create such a channel and use it without your application code ever realizing it. But nothing like this comes in the box: You would have to build it, or download or purchase it.
it has nothing to do with WCF....
if there is a connection between the computers, on the IP, then the message will get through...