Ultra VNC 1.0.2

Projects/CoVNC 2008. 4. 17. 16:44 Posted by soulfree >동네청년<

댓글을 달아 주세요

리눅스에서 원격데스크탑 접속

2008. 2. 4. 15:53 Posted by soulfree >동네청년<
원격데스크탑을 한꺼풀 벗겨볼 수 있을듯!

댓글을 달아 주세요

Where it came from, where it's going - Tim Waugh

Projects/Server 2007. 2. 28. 15:16 Posted by soulfree >동네청년<


Where it came from, where it's going

Tim Waugh


This article, which briefly explains what VNC is and what pieces of software have been written that use it and its ideas, was originally published (in Italian) in issue 2 of Red Hat Magazine. It was written using, and I have since reformatted it in DocBook. This version is more or less the same as the original; some URL references have been tweaked.

VNC is a thin client technology for using an X desktop (the graphical environment we use everyday). It stands for Virtual Network Computing and can be thought of as a software version of the “network computer” which never quite took off. If you have ever used the UNIX screen command, you might like to think of VNC as its graphical equivalent. You can start a desktop session, disconnect from it and then reconnect to it at will, even from a different X terminal. All of the applications are available exactly as before disconnecting.

In contrast, although X itself allows applications to display remotely, it does not provide this persistence; you cannot move an application window from one X server to another. Another thing that VNC allows you to do is to have several viewers all watching the same server. This can be useful in training environments for example.

The original VNC design and reference implementation arose from Olivetti Research Labs in Cambridge where it was used in a “teleport” system, whereby your desktop could follow you around the building, hopping to the nearest convenient terminal (an “active badge” on your clothing made this possible). Since those days AT&T bought the facility and the VNC engineers are now in a venture named RealVNC, a company which provides commercial support for the VNC product. Although it used to be the case that VNC releases were quite infrequent, since RealVNC took off they have been more regular. VNC is free software, licensed under the GNU GPL. This means that any modifications to the software must be made available in source form, a fact which has proven to be useful as we shall see later.

The differences between VNC and X should be made clear at this point, since the terminology can be quite confusing to the uninitiated. Both have clients and servers. For both, the server is where the desktop, with all the application windows, is stored. With X, the server is on the machine in front of you and drives the video card. An X client is an application that wants to display a window on the server, like a web browser or email application. A VNC client, in contrast, is an application that displays the desktop image to the user; normally the job of the X server. Both the VNC server and client perform tasks that the X server would normally do: maintaining the desktop image (in other words, the frame buffer) and displaying that image to the user.

The two independent parts are the client and of course the server and each can be running on a different platform. The protocol is designed to adapt to the amount of bandwidth available. It is also designed to make the client (the “viewer”) very simple, without requiring extensive computing resources. This makes it ideal for thin client deployments, diskless if need be, and this perhaps is the most convenient form of network computer made from commodity components.

VNC is in fact quite pervasive—it can run on anything from high end servers to hand-held devices such as palm pilots. The uVNC project even has an 8-bit port; remember the Commodore 64?

There is even a VNC viewer written in Java. This means that you can use it from your web browser on a machine that has had no special set up. Just point the browser at a special port on the server and it will serve up a Java applet ready to go. The port number will be 5800 plus the display number for the VNC server. The display number is used to identify different VNC servers on the same machine, in exactly the same way as X works. In fact, VNC servers and X servers share the same display number range, and so if there is already an X server running (usually on display number 0), a newly started VNC server will get display number 1. To use the Java viewer for that server, point a browser at http://machinename:5801/. Note that the Java applet uses the normal VNC port number (5900 plus display number). So, if you want to use a VNC server that is behind a firewall, you might want to open up that port. (More likely you will want to tunnel VNC over SSH—detailed further on.)

Needless to say, VNC runs on Red Hat Linux as well of course. In the latest release (Red Hat Linux 7.3) there is a VNC service that can be started on boot-up. This will start VNC servers for a configured list of users, each with their own assigned display number. To configure it, you need to edit the file /etc/sysconfig/vncservers and set which users should have VNC servers started for them, and with which display numbers.

In Figure?1, you can see an document being edited using the VNC Java applet running in Mozilla on Red Hat Linux. The only thing running locally is the browser, and any Java-enabled browser on any platform will do.

Figure?1.?Java VNC client

Java VNC client

Although VNC is the name of the technology as a whole, the protocol it uses is called RFB, which stands for Remote Frame Buffer. Conceptually you can think of a VNC client as a sort of abstracted video card. This “video card” happens to be over a network and is accessible only via the RFB protocol.

Compare this with how X traditionally works: the application may or may not be remote but the X server is running on the machine in front of you, showing you the application's window on your monitor. With VNC there is an addition: the X server machine may be different to the one that your monitor is connected to.

The X protocol is itself reasonably low bandwidth but it is difficult to compare it directly to RFB because they are at different levels: where X speaks in terms of lines and text and so on, RFB is only concerned with pixels, and mouse and keyboard events. There is no provision in RFB for storage at the viewer end other than the frame buffer itself, since this makes the viewer a simpler application.

On UNIX, the RealVNC server is essentially a modified XFree86 server, named Xvnc. It differs from VNC on Windows in the way it handles sessions. UNIX can have several X servers running at the same time, each with a different login, and VNC works just as any other X server would (since that is what it is). But Windows only has one session to use and so on that platform the VNC server attaches to that. This means that when you start a VNC server on a Windows machine you are sharing that existing session but on a UNIX machine a new session is started. There are however ways to share an existing session under UNIX, just like with Windows. Both types of sharing are useful in different circumstances.

When a VNC viewer first makes a connection to the server, they negotiate common ground for their capabilities. This allows implementations to be extensible to some degree. It is also at this initial stage that any authentication is performed. It is important to note here that this is only a simple authentication scheme to prevent casual misuse and no encryption is used at all in the mainstream version, although some implementations do have ways to do this.

From then on it is, perhaps surprisingly, the viewer and not the server that initiates messages. In effect the viewer repeatedly queries the server for any screen changes as well as transmitting input events such as typing. This leads to the bandwidth usage being adaptively self-limiting; the slower the network (or viewer), the less frequently updates can be requested. With a fast viewer and network, updates for tiny changes will be requested, but if the network is slow then several changes will be combined into one screen update. Commonly the viewer will only ask for updates every few seconds, or when the user moves the mouse or types on the keyboard. The illusion of constant updates can be maintained by asking for more updates when the screen actually does change; the idea is that usually several changes will happen very shortly after one another.

The server and viewer negotiate an “encoding” to use which they both understand and the specification lists some common ones. They include “hextile” (which breaks screen areas into tiles), “copyrect” (copying another area of the screen), “ZRLE” (a compressed variant) and “raw” for when the server is the same machine as the client. It turns out to be faster to transfer unencoded screen updates when it is all on the same machine.

The RFB protocol can be used in other ways than originally intended as well. One such way is scriptable remote control, which could be used for automating tasks with applications that were not designed with scripting in mind. You can run them in a VNC session and control the session using a program such as rfbplaymacro. This takes a script and translates it into RFB input events such as mouse movements, button presses and keyboard typing.

Another use of the RFB protocol is session playback, in other words recording a series of screen updates for later display. You might want to do this if you are setting up a “rolling demo” for a shop display. A simple way to achieve this is just to record the RFB screen updates as they happen into a file with a purpose written application. There are several which perform this function including rfbproxy, which was written for a demonstration machine on a trade show stand, and Jens Wagner's xrfbplayer (in the rfb package; see later).

The disadvantage of this approach is that only applications which understand the RFB protocol will be able to interpret the saved screen updates. However there is one utility named vnc2swf which converts this format into ShockWave Flash.

VNC is currently going in several directions. The fact that historically the Olivetti/AT&T releases were so slow has led to several independent VNC development efforts springing up. It will be interesting to see how these progress, now that the original VNC developers are working at RealVNC, a company entirely devoted to that project. I personally hope that some of the development forks will be merged back into the main RealVNC project. This is mainly possible because of the GNU GPL license, of course.

One development effort was started by Jens Wagner with his rfb project. This project is also licensed under the GNU GPL, although it is mostly a re-implementation rather than a modification. There are two main programs: x0rfbserver and xrfbviewer. The first is an implementation of the VNC server that can make VNC on UNIX act as it does on Windows. The way it works is that it shares your existing X session by watching the screen for updates. Unfortunately it can be quite slow to do this since it has to continually poll the screen (the same is true for the original Windows VNC server). The other program is a re-implementation of the VNC viewer application. It looks quite a lot prettier than the original—see Figure?2. It can also record sessions and play them back in the same way and using the same format as rfbproxy, and can create scripts that rfbplaymacro can use as well.



Another notable offshoot of VNC is the Tight VNC project started by Const Kaplinsky. This is a modification of the original VNC software, and so is also available in source form under the GNU GPL. Its original purpose was to enhance the original program by implementing a new encoding named “tight”. This new encoding was designed by analysing the bandwidth problems of the existing encodings, and for real sessions can provide much better bandwidth usage. Const was able to directly compare encoding efficiency with the standard encodings by using a saved session provided by the rfbproxy program and so could fine-tune its performance. Now, Tight VNC includes several other enhancements as well as bug fixes. Among them is JPEG compression (for lossy compression, if you do not mind slight loss of detail but want to use less bandwidth), local cursor handling (to prevent data transfer when you are just moving the mouse), and automatic SSH tunnelling for security. Currently Red Hat Linux ships with Tight VNC in preference to the original VNC.

The enhancements from the Tight VNC project are still largely not incorporated into the main VNC project, and this gave an opening for a company named Tridia VNC. By incorporating features from Tight VNC and the rfb project, adding a Windows installer and offering commercial support, they provided a central place for features and enhancements to go, when it looked like the Olivetti/AT&T VNC development had stagnated.

There has even been a VNC server implementation written for 8-bit microcontrollers, such as toasters and microwave ovens. The author of uVNC envisions devices like light dimmer switches and thermometers embedding a VNC server, and being able to control them over a network! For two weeks Adam Dunkels (its author) had hooked up a Commodore 64 to the Internet running uVNC on its 6510 processor. As far as I have been able to tell, there are no VNC-enabled toasters available as yet, but I'll keep my fingers crossed.

One of the problems with the VNC servers we have seen so far is that it is difficult to embed them into your own application if you need to. Also, if a bug is found in one, it most likely needs fixing in several others since they share the same heritage. One obvious way to make this better is to separate out the protocol engine and share it between all of the implementations; in other words make it into a library. One such library is libvncserver. To see why this is so useful, take the simple rfbproxy program I wrote as an example. It is so simple that it only works if the viewer is using the same resolution and colour depth as when the original recording was done. This is because it literally just remembers the bytes that were transferred originally, rather than reconstructing the screen as it was and acting as a VNC server for that. Had libvncserver existed when I wrote rfbproxy I would certainly have used it and rfbproxy would have been a better program for it. Perhaps one day I will re-write it that way.

One application using the libvncserver library is a program that acts as a gateway between the Windows Terminal Server protocol (RDP) and the protocol used by VNC. This program, rdp2vnc, was in fact the reason libvncserver was originally written. With it, you can use Windows Terminal Server just like a VNC server.

Another application that uses libvncserver is the KDE Desktop Sharing service, which is due to appear in KDE 3.1. This is a small application which allows you to share your existing KDE desktop. A similar feature is planned for the GNOME desktop environment as well. This style of desktop sharing gives very good integration into the rest of the desktop and will make it much easier for new users. However, as I understand it, it works in the same way as x0rfbserver and needs to poll the screen for updates. What is really needed is for the X server to be able to notify applications of changes to the screen, and in fact an X extension for tracking screen changes has been proposed recently. Another approach is to have an X module for VNC sharing, so the X server itself becomes the VNC server, eliminating the need for slow polling.

This problem is solved by Alan Hourihane's xf4vnc. This is exactly what is needed: a VNC server implementation as an XFree86 module, in particular for XFree86 4.2.0. This also solves another VNC problem, namely that XFree86 has made several advances since the version VNC was based on (3.3.x), and so VNC has been lagging behind ever since. In fact 3.3.x is no longer maintained at all which leaves VNC users in a bad situation. As well as providing an X driver as a drop-in replacement for the old Xvnc server, xf4vnc provides a module which can be used for VNC-enabling an existing session, in the same way that the KDE Desktop Sharing service works. In fact it will be better than the Desktop Sharing service since it will not need to poll the screen and as a result will be faster. The xf4vnc project is licensed under the GNU GPL, although that is incompatible with the license of XFree86 and so it will never be merged (but it can of course be used by everyone). It is quite a recent development and so is not being shipped by any free software vendors yet to my knowledge. It is based on the original VNC and therefore unfortunately does not have many of the enhancements of some of the other VNC projects.

VNC can be used as a teaching tool, for either teleteaching where the students are physically remote from the teacher, or class teaching in the same room. In this mode generally the teacher's screen is viewable by the students but they may not control it. When there are just a few students, all is well and good, but VNC does not scale to large numbers of viewers. One approach to solving the problem is to use multicast where the same IP packet is sent to multiple machines, rather than the unicast method (one IP packet per machine) that appears in standard VNC. This modification has been made in the MulticastVNC program.

With some teaching environments, such as computer troubleshooting, the teacher needs to be able to see and control the text console as well as the graphical environment. Imagine for example the class entitled “setting up an X server” or “recovering from boot-up problems”. There is hardware available to solve this problem, but it is quite expensive. An adequate but not as comprehensive solution can be made from software. One attempt to do this is the vtgrab project. This aims to be a text mode equivalent of VNC for the actual text console of a Linux machine. It can replicate the server machine's console on the teacher's machine in a window and is designed to be usable over a serial link (so that it does not rely on a working network connection). The teacher can switch between consoles and can see console switches made by the student; the teacher can also type at the remote console. If the student's machine is switched to a console running X, then it automatically starts x0rfbserver on the student's machine and a VNC viewer on the teacher's machine. As far as that goes it works well enough but there is plenty more to do and it will never fully replace a hardware solution. It can not start until the operating system is booted, whereas a hardware solution would allow remote BIOS setting changes for example.

There are several areas in which the current VNC efforts are lacking. One often requested feature is the ability to print things remotely and transfer files easily as part of VNC. Solutions to these problems, so the argument goes, exist already independently of VNC—network printer sharing, in the printing case, and FTP or scp in the file transfer case—but it is asked for often enough that there obviously needs to be some better integrated way of doing it. Development efforts in this area are sporadic but frequent although there is not much progress to report yet. It seems clear though that there is no need to invent another way of transferring print jobs between machines for example; all that is needed is integration to an existing method. The eSVNC project seems to be taking steps in this direction.

One interesting possible future direction would be the ability to transfer sound as well as images. In a shared session it would be advantageous to be able to talk to the person whose session you are sharing. Several low bandwidth methods are possible and with the (admittedly gradual) rise in popularity of Ogg Vorbis perhaps someone will find enough incentive to attack this problem. Even an out-of-band way of writing text to each other would be a good first step in this direction.

Perhaps the most often requested feature, and surely the most needed, is encryption. In the reference implementation from RealVNC, a challenge-response authentication scheme is possible. However even this is unfortunately vulnerable to a man-in-the-middle attack. This is in spite of the fact that it is possible to do authentication securely as well as encrypting all communications to boot (for example SSH). VNC was designed to get its job done on a trusted network and so security was never really a goal. In this day and age though, it is more and more common for people to want to share desktops across the Internet using their broadband connections making security much more of an issue.

Luckily it is possible to “tunnel” a normal VNC session over a properly authenticated connection such as SSH or Zebedee. In the short term this is adequate, and not all that difficult to set up, but it is a huge shame that you need this extra step.

There are many more VNC-related projects underway than those I have mentioned here, and features which I have not pointed out. If there is something particular that you are after it may already exist; the links in this article are probably a good place to start looking.


'Projects > Server' 카테고리의 다른 글

mysql 데이터 백업 및 복구  (0) 2007.03.07
Linux Shadow Password HOWTO  (0) 2007.03.07
Where it came from, where it's going - Tim Waugh  (0) 2007.02.28
리눅스 swap memory  (0) 2007.02.23  (0) 2007.02.23
리눅스 페도라 4 에서 oracle xe 설치 하기  (0) 2007.02.22

댓글을 달아 주세요

Virtual Network Computing

Projects/CoVNC 2007. 2. 14. 17:04 Posted by soulfree >동네청년<

Virtual Network Computing

From Wikipedia, the free encyclopedia

(Redirected from Vnc)
Jump to: navigation, search

Virtual Network Computing (VNC) is a desktop sharing system which uses the RFB (Remote FrameBuffer) protocol to remotely control another computer. It transmits the keyboard presses and mouse clicks from one computer to another relaying the screen updates back in the other direction, over a network.

VNC is platform-independent ? a VNC viewer on any operating system can connect to a VNC server on any other operating system. There are clients and servers for almost all operating systems and for Java. Multiple clients may connect to a VNC server at the same time. This technology's popular uses include remote technical support, and accessing files on one's work computer from one's home computer.

VNC was originally developed at AT&T. The original VNC source code and many modern derivatives are open source under the GNU General Public License.



[edit] History

VNC was created at the Olivetti & Oracle Research Lab, which was then owned by Olivetti and Oracle Corporation. In 1999 AT&T acquired the lab, and in 2002 closed down the lab's research efforts.

The name originates from a thin client asynchronous transfer mode (ATM) network computer called the Videotile, which was essentially an LCD with a pen input and a fast ATM connection to the network. VNC is essentially a software-only version of this "ATM Network Computer".

Developers who worked on VNC while still at the AT&T Research Lab are:

[edit] Operation

A VNC a client and a server. The server is the program on the machine that shares its screen, and the client (or viewer) is the program that watches and interacts with the server.

The VNC protocol is very simple, based on one graphic primitive: "Put a rectangle of pixel data at a given x, y position". That is, the server sends small rectangles of the framebuffer to the client. This in its simplest form uses a lot of bandwidth, so various methods are used to reduce it. For example, there are various encodings ? methods to determine the most efficient way to transfer these rectangles. The VNC protocol allows the client and server to negotiate which encoding will be used. The simplest encoding, which is supported by all clients and servers, is the raw encoding where pixel data is sent in left-to-right scanline order, and after initial setup, then only transfers rectangles that change. Because of that, this encoding works very well if only a small portion of the screen changes from one frame to the next (like a mouse pointer moving across a desktop, or text being written at the cursor), but bandwidth demands get very high if a lot of pixels change. (Full screen video is the most radical example of this.)

VNC by default uses TCP ports 5900 to 5906, each representing the corresponding x screen (ports 5900 to 5906, for screens :0 to :6). A Java viewer is available in many implementations such as RealVNC on ports 5800 to 5806, following the same pattern. These ports can be changed.

Most Windows computers can only use a single port because Windows lacks the multisession features of UNIX-based servers. The default display number for Windows-based computers is 0 which maps to TCP port 5900.

[edit] Security

By default, VNC is not a secure protocol. While passwords are not sent in plain-text (as in telnet), brute-force cracking could prove successful if both the encryption key and encoded password are sniffed from a network. For this reason it is recommended that a password of at least 8 characters be used. There is also an 8-character limit on some versions of VNC. If a password is sent exceeding 8 characters, the excess characters are removed and the truncated string is compared to the password.

However, VNC may be tunnelled over an SSH or VPN connection which would add an extra security layer with stronger encryption. SSH clients are available for all major platforms (and many smaller platforms as well); SSH tunnels can be created from UNIX clients, Windows clients, Macintosh clients (including Mac OS X and System 7 and up) ? and many others.

UltraVNC supports the use of an open-source encryption plugin which encrypts the entire VNC session including password authentication and data transfer. It also allows authentication to be performed based on NTLM and Active Directory user accounts.

RealVNC offers high-strength encryption as part of its commercial package.

Workspot released AES encryption patches for VNC.

On July 31, 2005, Tridia announced that they were discontinuing development of their free product Tridia VNC and suggested users instead pay for their commercial remote administration software iTvity, claiming that software based on the VNC protocol is unsuitable for deployment in a business environment due to design deficiencies in VNC itself.[1]

[edit] Comparison of VNC software

VNC softwareClientServerRuns on WindowsRuns on Mac OS XRuns on LinuxFLOSSJava viewerEncryptionMultiple Sessions
RealVNC Free [2]YesYesYesNoYesYesYesNo
RealVNC EnterpriseYesYesYesYesYesNoYesYes
TightVNC [3]YesYesYesNoYesYesYesNo
UltraVNC [4]YesYesYesNoNoYesYesYes (plugin)
Chicken of the VNC[5]YesNoNoYesNoYes
Vine Server(OSXvnc) [6]NoYesNoYesNoYes
Apple Remote Desktop[7]YesYesNoYesNoNoYes

[edit] See also

[edit] Further reading

[edit] External links

Wikimedia Commons has media related to:

'Projects > CoVNC' 카테고리의 다른 글

CListBox  (0) 2007.02.21
부요리눅스의 클립보드  (0) 2007.02.20
Virtual Network Computing  (0) 2007.02.14
클립보드의 정의  (0) 2007.02.14
Ultra VNC 소개  (0) 2007.02.13
vnc 소개  (0) 2007.02.09

댓글을 달아 주세요

Remote Administrator

Projects/Server 2007. 2. 14. 16:57 Posted by soulfree >동네청년<

Radmin이 무엇인가요?

1. Radmin이란

RAdmin은 자신의 컴퓨터에서 리모트 컴퓨터를 원격 제어하는 프로그램으로서 파일 전송, NT 보안, 텔넷 등의 주요한 기능이 포함되어 있습니다.

RAdmin을 사용하면 리모트 컴퓨터를 내 컴퓨터에서 전체 화면이나 윈도창으로 볼 수 있습니다. 마우스나 키보드의 모든 기능이 리모트 컴퓨터로 전달되어 리모트 컴퓨터가 마치 자기 앞에 있는 것처럼 작업을 하실 수 있을 겁니다.

RAdmin은 인터넷이나 LAN상의 어느 곳에 있더라도 리모트 컴퓨터를 제어할 수 있습니다. LAN으로 연결되지 않고 모뎀을 통해서 연결되어 있더라도 작업을 하실 수 있을 겁니다.

만약에 LAN으로 리모트 컴퓨터가 연결되어 있다면 거의 실시간으로 작업을 할 수 있습니다. 풀 스크린모드로 RAdmin을 사용한다면 리모트 컴퓨터에서 작업하고 있다는 것을 잊어 버릴 정도로 빠른 속도감을 만끽하실 수 있을 겁니다.

RAdmin은 매우 안전하고 믿을 수 있는 소프트웨어입니다. RAdmin에는 패스워드 프로텍션, IP 필터, TCP 포트 변경 등의 보안 기능이 있습니다.

RAdmin을 사용하면 리모트 컴퓨터에서 내 컴퓨터처럼 프로그램을 사용할 수 있을 뿐만 아니라 파일복사, 시스템 종료, 시스템 재시작, 로그오프, 로그온 등의 작업을 할 수 있습니다.


RAdmin Server
RAdmin Viewer
RAdmin working

2. RAdmin의 구조

RAdmin은 서버와 클라이언트로 이루어져 있으며 Radmin은 서버와 클라이언트에 같이 설치되어 있어야 하며, TCP/IP를 통해서 서버에서 클라이언트에 접속하게 해 줍니다.

3. RAdmin과 다른 프로그램 비교

속도 :
Radmin은 다른 어떤 원격제어 시스템보다 빠릅니다. 예를 들어 AT&T 제품인 VNC(Virtual Network Computing)보다 150배 정도 빠르며, pcANYWHERE, Timbuktu, Remote Control, LapLink 중에 가장 빠른 성능을 보여 줍니다.




속도 테스트 다운로드 받기

기능 :

파일전송, NT 보안 지원, 멀티 언어 지원, 텔넷 지원, 원격 종료 등

Radmin 주요 기능

서비스로 동작합니다.

RAdmin 서버는 WinNT와 Win9X하에서 시스템 서비스로 실행되며, 리모트에서 사용자가 접근할 수 있도록 해 줍니다.

멀티 연결 지원.

Radmin 서버는 다중 원격 제어를 지원하고 한 화면에 여러 세션을 보여 줍니다.

3가지 연결 화면 모드 지원

풀스크린 모드는 내 컴퓨터의 전 화면에 리모트 스크린을 보여줄 수 있습니다. 스케일링 모드는 지정한 크기의 윈도에 리모트 스크린을 보여줄 수 있기 때문에 여러 군데 원격컴퓨터를 한 화면에 띄울 수 있습니다.

Video hook driver technology 사용

Radmin은 Windows NT 4.0에서 성능을 향상시키기 위해 video hook kernel mode driver를 사용합니다. 이 기술은 리모트 컴퓨터에서 매우 빠른 속도로 작업을 할 수 있게 해 줍니다. 이 드라이버의 Win2000 버전은 Radmin 다음 버전에 포함될 예정입니다.

File transfers

내 컴퓨터와 리모트 컴퓨터가 서로 파일 전송이 가능합니다.

Remote shutdown feature

리모트 컴퓨터와 스크린 모드로 접속하지 않고도 리모트 컴퓨터를 종료시킬 수 있습니다. 물론 스크린 모드로 접속해서 사용자 로그인-로그오프, 시스템 재시작-종료가 가능합니다.

Telnet server

Radmin 서버는 Windows NT에서 동작할때 리모트 컴퓨터에 텔넷으로 접속이 가능합니다.

Windows NT security support

당신은 특정 유저나 그룹에 원격제어, 원격 감시, 텔넷 접속, 파일 전송등의 권리를 부여할 수 있습니다. 유저가 WinNT 도메인에 로그한다면 Radmin Viewer는 Radmin 서버에 연결하기 위해서 유저이름과 패스워드를 사용할 것입니다.

Password protection

윈도 NT 보안이 끊어진다면 패스워드를 통해 리모트 컴퓨터 접근 제어할 수 있습니다.

IP filter

이 기능은 특정 IP나 서브넷만이 Radmin 서버에 접근이 가능하도록 한다.

Radmin supports Hi-resolution modes

Radmin은 2048 X 2048 X 32bit color까지 해상도를 지원합니다.

시스템 요구사항


윈도가 설치되어 있다면 Radmin이 동작할 것입니다. 8Mb RAM에 Win95가 설치되어 있는 386에서도 동작합니다.


반드시 TCP/IP가 설치되어 있어야 합니다.

Windows 95/98/Me/2000/XP :
TCP/IP만 설치되어 있으면 됩니다.

Windows NT 4.0 :
서비스팩 4.0 이상이 필요합니다. 드라이버나 서비스를 인스톨하고자 한다면 관리자 권한이 필요합니다

Radmin 보안

Radmin을 설계하는데 보안 문제에 가장 많은 주의를 가졌습니다. Radmin 보안은 다음과 같습니다.:

Radmin 2.0 은 WindowsNT/2000 user level security를 지원합니다. 특정 유저나 그룹에 원격제어 권한을 부여할 수 있습니다.

WindowsNT security support이 동작하지 않는다면 리모트 컴퓨터의 접근은 패스워드로 관리됩니다. Radmin은 challenge-response password authentication method를 사용합니다. 이 방법은 윈도NT에서의 인증 방법와 유사하지만 프로토콜에서 더 큰 보안키를 사용합니다.

RAdmin은 암호화 모드를 지닙니다. 여기서 스크린 모드, 마우스 움직임, 키보드 입력 등 모든 데이터가 암호화됩니다. 랜덤하게 생성되는 키를 갖는 128비트 암호화가 사용됩니다. 파일 전송이나 텔넷 등과 같은 모든 다른 접속 모드가 디폴트로 암호화되는 반면 원격 제어 접속에 대해 암호화는 옵션입니다.

RAdmin 서버는 모든 액션을 로그 파일로 기록합니다.

RAdmin 서버는 IP 필터 테이블을 갖습니다, 만약 이 테이블을 사용한다면 특정 네트워크나 특정 IP 어드레스만 Radmin server에 접근하도록 할 수 있습니다.

RAdmin 서버는 자가 진단 코드 방을 합니다. 따라서 자신의 코드가 바뀌지 않도록 방어합니다.

RAdmin에서 사용되는 모든 알고리즘은 산업 표준 규격(DES, MD5)을 따름니다.

Remote Administrator 설치가이드

1. 알어드민(RAdmin, Remote Administrator) 사용 환경
2. 프로그램 설치하기
3. 알어드민 서버 보안(암호) 설정하기
4. 원격컴퓨터 제어하기

1. 알어드민(RAdmin, Remote Administrator) 사용 환경

Remote Administrator를 설치하기 위해서는 두 컴퓨터가 인터넷이나 LAN으로 서로 연결되어 있어야 하고, TCP/IP 프로토콜이 설치되어 있어야 합니다.

RAdmin은 리모트 컴퓨터와 원격으로 제어할 컴퓨터에 모두 설치해야 합니다.

2. 프로그램 설치하기

radmin 21k.exe 다운로드
위의 프로그램을 다운로드 받아 '현재 위치에서 이 프로그램을 실행'을 선택합니다.
다음->동의함->다음->설치시작->완료를 선택합니다.

3. 알어드민 서버 보안(암호) 설정하기

다른 사람이 이 컴퓨터를 임의로 제어할 수 없도록 암호 설정이나 TCP 포트를 변경합니다.
시작->프로그램->Remote Administrator v2.1->Settings for Remote Administrator Server를 실행해서 '암호 설정/변경'을 클릭합니다.

4. 원격컴퓨터 제어하기

시작->프로그램->Remote Administrator v2.1->Remote Administrator viewer를 실행해서 사용을 선택합니다.
위에서 연결 -> 새 연결을 클릭해서 원격 컴퓨터의 IP 주소(나 도메인(을 입력하고 '연결'를 선택합니다.

정상적으로 접속이 되면 아래와 같이 원격제어 스크린이 나오며, 원격컴퓨터를 직접 제어할 수 있습니다.

Remote Administrator 프로그램 그룹 구성

Remote Administrator viewer
Settings for Remote Administrator server
Start Remote Administrator server
Stop Remote Administrator server

알어드민(Radmin)은 뷰어와 서버 두 가지 프로그램으로 구성되어 있습니다. 뷰어는 원격접속하기 위해 사용하는 프로그램이며, 서버는 원격에서 접속할 수 있도록 해 주는 프로그램입니다.

Remote Administrator viewer

리모트 컴퓨터를 원격제어, 파일전송, 종료하기 위해 사용하는 프로그램입니다. 이 프로그램을 실행시켜서 원격 컴퓨터에 접속합니다.

Settings for Remote Administrator server

알어드민 서버 설정을 위해 사용하는 프로그램입니다. 알어드민 서버를 시스템 서비스로 인스톨하거나 제거하는 명령어와, 패스워드 보안, NT 유저 레벨 보안, IP 필터, TCP 포트 변경, 접근 거부 등 보안 관련 작업을 하기 위해 사용합니다.

Start Remote Administrator server

Radmin 서버를 스타트 시키면 시스템 트레이 박스 Radmin 서버 아이콘이 생김니다. Radmin 서버를 스타트 시켜야 다른 컴퓨터가 원격에서 접근할 수 있습니다.

Stop Remote Administrator server

Radmin 서버를 스탑시키면 다른 컴퓨터가 원격에서 접근할 수 없습니다.

Remote Administrator viewer

Remote Administrator viewer 화면 설명
Remote Administrator viewer 메뉴
원격컴퓨터로 연결하기
중간 서버를 통해 리모트컴퓨터 제어

Remote Administrator viewer 화면 설명

원격 컴퓨터에 처음 연결을 할 때 새연결 아이콘을 클릭해서 원격 컴퓨터의 아이피를 입력하면 연결할 수 있습니다. 처음 연결한 경우가 아니라면 연결모드를 선택한 후에 연결리스트를 더블 클릭하면 원격컴퓨터에 연결할 수 있습니다.

Remote Administrator viewer 메뉴

Remote Administrator viewer 연결 화면

알어드민(RAdmin) 서버의 TCP 포트가 4899 번이 아니라면 TCP 포트를 변경해 주어야 합니다.

중간 서버를 통해 연결

Settings for Remote Administrator server

Settings for Remote Administrator server 메인 화면
Remote Administrator 서비스
알어드민 서버 암호 설정
NT 유저 레벨 보안 사용
옵션 메인 화면(IP 필터, TCP 포트, 로그파일, 연결시도 알림)
옵션 설정 예

Settings for Remote Administrator server 메인 화면

Remote Administrator 서비스 설치

서비스 설치를 해야만 부팅할 때 알어드민(RAdmin, Remote Administrator) 서버가 시스템 서비스로 동작합니다. 항상 알어드민 서버가 동작하고 있을 필요가 없을 때는 서비스 제거를 한 후에, 사용할 때 알어드민 서버를 실행(Start Remote Administrator server)시켜 주어도 됩니다.

알어드민 서버 암호 설정

아무나 접속하지 못하도록 암호를 설정하시기 바랍니다. 여기서 암호 대신에 NT 유저 레벨 보안을 설정할 수도 있습니다.

NT 유저 레벨 보안 사용

암호 대신 윈도 NT 유저 레벨 보안을 사용할 수 있습니다. 이 기능은 NT/2000/XP 에서만 지원 되며, 윈도에 등록된 사용자 아이디와 사용자의 암호, 도메인(또는 작업그룹)을 이용해서 외부에서 접속을 하는 보안입니다. 각 사용자별로 모드별 연결 권한을 할당할 수 있습니다.

옵션 메인 화면

알어드민(RAdmin, Remote Administrator) 서버는 암호 설정뿐만 아니라 TCP 포트 변경과 IP 필터 기능에 의해 완벽한 보안을 제공합니다.
로그파일기록 기능은 외부에서 원격 접근 시도한 PC의 IP와 시간을 기록하게 됩니다.
접근허가묻기 기능을 이용하면 이 PC를 사용하는 사용자나 먼저 원격제어를 하고 있는 사용자가 외부에서 또 다른 원격제어를 시도를 차단할 수 있습니다.

로그파일기록과 IP 필터 기능이나 접근허가묻기의 자동차단 기능을 이용해서 원격에서 접근한 PC의 원격 접속은 차단하고 그 PC의 IP만을 기록할 수 있습니다.

옵션 설정 예

TCP 포트를 변경한 알어드민 서버에 연결하기 위해서는 연결하는 PC에 설치된 Remote Administrator viewer의 TCP 포트도 변경해 주어야 합니다

Remote Screen

Ctrl+Alt+Del 보내기
클립보드 데이타 전송하기
해상도 변경
업데이트 속도 조절

Remote Screen 설명

원격제어 모드로 접속을 하면 아래와 같은 원격제어 화면이 나타납니다. 원격제어 화면에서 'Ctrl + F12'를 누르거나 알어드민(RAdmin) 아이콘을 클릭하면 아래와 같은 메뉴가 나타납니다. 이 메뉴에서 원격제어 화면에 사용하는 Tool과 설정을 변경할 수 있습니다.

원격컴퓨터 연결하기


알어드민 뷰어 메인 화면
원격제어모드로 연결하기
감시모드(보기모드)로 연결하기
파일전송 모드로 연결하기
원격종료 모드로 연결하기
Telnet 모드로 연결하기

알어드민 뷰어 메인 화면

알어드민으로 원격 컴퓨터에 처음 접속하는 경우는 새연결로 연결리스트를 만들어서 연결하면 됩니다. 기존에 접속했던 연결리스트가 있으면 연결모드를 선택한 후에 연결리스트를 클릭하면 접속을 할 수가 있습니다.

원격제어모드로 연결하기

원격제어 모드로 연결하면 내 컴퓨터의 마우스와 키보드를 이용해서 원격컴퓨터를 마음대로 사용할 수 있습니다. 내 컴퓨터 모니터안에 원격컴퓨터의 모니터가 다시 생성되서 마치 원격컴퓨터 앞에 앉아 있는 것처럼 사용이 가능합니다.

감시모드(보기모드)로 연결하기

감시모드는 마치 원격컴퓨터 앞에 앉아 있는 것처럼 리모트컴퓨터의 모니터를 내 컴퓨터 모니터 앞에서 볼수는 있지만 내 키보드와 마우스를 이용해서 원격컴퓨터를 조작할 수는 없습니다.

파일전송 모드로 연결하기

파일전송 모드로 접속하면 파일이나 폴더를 반대편으로 드래그해서 서로 복사할 수 있습니다.

원격종료 모드로 연결하기

원격종료는 제어모드로 연결하지 않은 상태에서 원격컴퓨터를 종료할 수 있습니다. 원격종료는 재시작, Shutdown(파워오프전 종료), 파워오프, 로그아웃 중 하나를 선택해서 실행할 수 있습니다.

Telnet 모드로 연결하기

텔넷모드로 접속을 하면 원격컴퓨터의 명령 프롬프트 화면이 내 컴퓨터 모니터에 생성이 되어 각종 명령어를 직접 입력할 수 있습니다.

중간 서버를 통해 사설 IP를 사용하는

PC 제어

알어드민은 직접 연결되어 있지 않더라도 두 PC와 동시에 연결된 PC를 이용해서 원격제어가 가능합니다.

먼저 인터넷에 연결된 PC에 대한 연결리스트를 만듭니다.

사설 IP를 접속할 연결리스트를 만듭니다.
이때 중간서버를 통해 연결을 체크한 후에 인터넷에 연결된 PC의 연결리스트를 선택해 줍니다.

이제 사설 IP 연결리스트를 클릭한다면 연결이 가능할 겁니다.
만약 중간 알어드민서버와 사설 IP의 알어드민 서버에 암호가 설정되어 있다면 첫번째 묻는 암호는 중간 서버에 설정된 암호이며, 두번째 묻는 암호는 사설 IP에 설치된 알어드민 서버의 암호입니다.

아이피공유기내의 사설IP를 쓰는 원격컴퓨터제어

아이피공유기를 사용하는 네트워크

알어드민으로 아이피공유기 내부 PC 연결하기

아이피공유기를 사용하는 경우 외부에서 아이피공유기내의 PC를 제어하기 위해서는 공유기의 WAN IP로 접속해야 하고, 공유기에서 내부 PC의 알어드민 서버로 접속할 수 있도록 NAT 방화벽을 오픈해 주어야 합니다.

소호라우터에서 내부 PC로 알어드민의 TCP 포트 연결하기

아이피공유기에서 내부 PC로 알어드민 접속을 가능하게 하는 방법은 두가지가 있습니다.
하나는 TCP 포트를 포워딩하는 방법이고, 다른 하나는 DMZ Host를 이용하는 것입니다.
아래는 Sohomate 의 Soho Router에 대한 설정의 예입니다. 참고하셔서 자신이 가지고 있는 공유기에도 적용을 하시기 바랍니다.

DMZ Host 라는 용어는 모든 공유기에서 같이 사용하는 용어이지만 TCP 포트 포워딩을 설정하는 방법은 각기 용어가 상이합니다.

Soho Router 는 Virtual Server 라고 하며, Linksys Router 에는 Forwarding 이라고 합니다. 일부 공유기는 Local Server 라고도 합니다.
공유기 설명서에 보시면 Web 서버나 FTP 서버를 설정하는 방법이 나와 있는데 이것이 아이피공유기에서 TCP 포트를 포워딩하는 방법을 설명하는 것입니다.

아이피공유기의 기본 IP인를 인터넷 익스플로러에 입력하면 아래와 같은 로그인 창이 뜹니다. 패스워드 입력란에 'admin' 이라고 입력한 후에 Log in 을 클릭하면 아이피라우터를 설정할 수 있습니다.
알어드민으로 접속을 할 때는 이곳에 있는 WAN IP 주소로 접속을 해야  


아이피공유기의 기본 IP인를 인터넷 익스플로러에 입력하면 아래와 같은 로그인 창이 뜹니다. 패스워드 입력란에 'admin' 이라고 입력한 후에 Log in 을 클릭하면 아이피라우터를 설정할 수 있습니다.
알어드민으로 접속을 할 때는 이곳에 있는 WAN IP 주소로 접속을 해야 합니다. 에서 확인요

Virual server를 이용해서 원격컴퓨터제어

왼쪽 메뉴에서 Virtual Server를 클릭해서아래와 같이 설정을 해 주어야만 외부에서 아이피공유기 내부의 PC를 원격제어할 수 있습니다.
여기서 Service Ports는 알어드민 서버가 사용하는 TCP 포트(기본 : 4899)이며, Server IP는 원격으로 제어할 알어드민 서버가 설치된 PC의 사설 아이피(예,입니다.
이렇게 설정한 후에 Enable 에 체크한 후에 Save를 클릭하고 Reboot 를 클릭한다면 외부에서 접속할 환경 설정이 끝나는 것입니다. 에서 확인요

DMZ를 이용해서 원격컴퓨터제어

DMZ란 '비무장 지대'를 나타내는 군사용어에서 사용하듯이 아이피공유기의 NAT 방화벽이 해제되어 외부에 노출되는 PC를 의미합니다.
이런 경우는 인터넷에 공유하지 않은 PC 하나만 단독으로 인터넷에 직접 연결되어 있는 것과 동일한 환경에 놓이게 됩니다.
DMZ host의 알어드민 서버가 설치된 PC의 IP 주소(예,을 입력하면 외부에서 이 PC를 원격 제어가 가능합니다.
아이피를 입력하고 Enable를 체크하고 'Save'를 클릭한 후에 'Reboot'를 클릭하면 설정이 적용됩니다. 에서 확인요

유동IP를 사용하는 원격컴퓨터 제어

유동IP를 사용하는 원격컴퓨터에 아이피 변경과 관계없이 수시로 접속하기 위해서는 IP 대신에 도메인(예,을 이용해서 접속해야 합니다.
네임아이피서비스(를 가입한 후에 네임아이피클라이언트 프로그램을 원격컴퓨터(유동IP)에 설치하면 네임아이피클라언트가 IP가 변경되면 수시로 네임아이피 서버로 변경된 IP를 통보하게 됩니다.

다른 컴퓨터에서 원격컴퓨터에 도메인(예,으로 접속을 하게 되면 네임아이피 서버가 도메인(에 대한 IP(예,를 알려주어서 유동IP를 사용하는 컴퓨터에 접속을 할 수 있게 됩니다.

알어드민으로 원격컴퓨터 접속하기

알어드민으로 원격컴퓨터에 연결을 할 때 IP 주소 대신에 컴퓨터이름(도메인)을 입력해서 연결을 합니다.

중간서버를 이용해 원격컴퓨터에 연결하는 사용자관리

중간서버를 이용해 다수의 원격컴퓨터에 연결하는 사용자(Viewer) 관리

(1) 외부에서 접근하는 사용자들을 관리하는 관리자 PC의 IP만 원격제어할 모든 PC의 IP 필터에 등록합니다.

(2) 외부에서 PC를 원격제어할 때 중간 서버에 관리자 PC 연결리스트를 선택하고 원격제어할 PC의 IP를 IP 주소에 입력해야 합니다.

(3) 관리자 PC에서는 각종 서버 보안을 설정합니다.
관리자 PC의 접근을 차단하면 외부에서 관리자 PC 뿐만아니라 다른 모든 PC에 접근을 할 수가 없습니다.
접근허가묻기를 체크하고 자동거부를 선택하면 관리자의 승인을 받아야만 내부 컴퓨터에 연결을 할 수가 있게 됩니다.

IP Scanner를 이용해 꺼져 있는

원격컴퓨터 켜기

컴퓨터와 랜카드의 Wake-on-LAN 기능을 이용해서 원격에서 켜는 방법입니다.

Wake on-LAN 기능은 LAN 상의(WAN 상이 아님)의 PC를 원격에서 켤수 있는 기능입니다. 따라서 인터넷을 통해서 원격에 있는 컴퓨터를 켤 수는 없습니다.
그러나 약간만 응용해도 원격에서 이 기능을 이용해서 컴퓨터를 켤 수가 있습니다.


  • 꺼져 있는 컴퓨터의 마더 보드에서 Wake-on-LAN 기능 지원
  • 꺼져 있는 컴퓨터의 랜카드에서 Wake-on-LAN 기능 지원
  • 꺼져 있는 컴퓨터의 LAN 상의 2대 이상의 컴퓨터가 존재
  • 이 중 한대는 반드시 켜져 있어야 함.
  • 켜져 있는 있는 컴퓨터에 알어드민과 ip scanner가 설치되어 있슴.

    이러한 조건일때 원격에서 켜져 있는 컴퓨터에 원격으로 접속을 한다면 Wake-on-LAN 기능을 지원하는 모든 컴퓨터는 ipscanner를 이용해서 켤 수가 있습니다.
    또한 알어드민도 설치되어 있다면 끄고 켜는 것을 자유자재로 할 수 있을 겁니다.

    모든 컴퓨터가 꺼져 있는 경우는 방법이 없으며 LAN상의 컴퓨터가 한대 뿐일때도 방법이 없습니다.

  • 8. Windows XP 방화벽에서 Radmin 포트 오픈하기

    바탕화면 내 컴퓨터를 더블 클릭합니다.

    내 네트워크 환경을 더블 클릭합니다.

    네트워크 연결 보기를 더블 클릭합니다.

    인터넷에 연결되는 랜카드에 해당하는 로컬영역연결을 클릭한 후에 오른쪽 마우스 버튼을 눌러 나타나는 창에서 '속성'을 클릭합니다.

    '고급' 탭을 누른 후에 설정을 클릭합니다.

    1. '사용 안함'을 클릭하면 XP 방화벽이 해제되고 Radmin 서버에 접근할 수 있습니다.

    2. XP 방화벽을 해제하지 않은 상태로 Radmin 서버에 접근하려면 '예외' 탭을 누릅니다.

    '포트 추가'를 클릭합니다.

    이름에 'radmin'이라고 입력하고 포트 번호에 Radmin 서버에 설정되어 있는 포트 번호를 입력합니다.

    TCP 가 체크되어 있어야 합니다. Radmin은 TCP 포트를 사용하기 때문입니다.

    아래는 기본 포트로 설정되어 있는 '4899'번 포트를 사용할 때 설정하는 예제입니다.

    모든 설정이 끝나고 확인을 누르면 아래와 같은 radmin 서비스가 나타나고 체크박스에 체크가 되어 있으면 외부에서 연결할 수 있습니다.

    그래도 연결이 안된다면 홈페이지 초기화면 에 접속하셔서 포트체크를 해 보시기 바랍니다.'open'이라고 나와야 하며, 'blocked'라고 나온다면 방화벽 해제를 잘못 하신 것이니 다시 순서대로 따라 해 보시기 바랍니다.

    Remote Administrator 자주하는 질문

    1. 알어드민 설치후 반드시 해야 될 일이 있습니다
    2. Radmin 설치했는데 연결이 안됩니다.
    3. Radmin을 삭제하고 싶습니다.

    댓글을 달아 주세요

    vnc 소개

    Projects/CoVNC 2007. 2. 9. 16:12 Posted by soulfree >동네청년<
    X윈도우도 원격으로「VNC」

    한기철 (마이크로소프트웨어 리뷰어) ( 마이크로소프트웨어 )   2003/07/21
    VNC(Virtual Network Computing)는 GNU GPL을 따르는 오픈소스 프로그램이다. VNC는 원격지 서버의 화면을 보여주는(앞서 소개한 프로그램들의 기본 기능에 해당하는) 기능만 제공한다. 이 간결함이 VNC의 매력이다.

    VNC를 이용해 원격지 서버에 접속해 불러온 원격지의 데스크톱

    TCP/IP 네트워크가 가능한 상황이라면 파일을 주고받는 기능은 FTP 등을 이용할 수 있으며, 채팅은 별도의 채팅 프로그램 등을 이용하면 된다. 카피 앤 페이스트 기능은 자주 사용하지 않을 수 있다. 즉, VNC는 핵심 기능만 간결하게 제공하는 무료 프로그램이다.

    VNC의 설정 화면, 그림에 보이는 내용 정도가 설정의 전부라 할 수 있다.

    앞에서 살펴본 3개 제품은 원격지 서버를 윈도우만 지원하지만 VNC의 경우는 윈도우, 리눅스, 매킨토시, 솔라리스 등을 지원하므로 리눅스 X윈도우에서 매킨토시 화면을 보거나 윈도우에서 솔라리스의 CDE(Common Desktop Environment)를 볼 수 있다. 이러한 다양한 플랫폼의 원격지 서버를 단일 클라이언트(뷰어)를 통해 접근할 수 있다는 점이 VNC의 가장 큰 장점이라 하겠다.

    제품 사양
    서버 운영체제윈도우 9x/ME/NT4/2000/XP
    클라이언트 운영체제윈도우 9x8/ME/NT4/2000/XP
    홈페이지, http;//

    VNC 뷰어의 경우 자바로 작성된 뷰어를 통해 이들 플랫폼 외에 윈도우 CE 등을 사용하는 모바일 장비 등 직접적으로 지원하는 뷰어가 없는 플랫폼에서도 VNC 서버에 접근할 수 있다. VNC는 RFB라는 프로토콜을 이용해 통신하며 AT&T Labs Cambridge에서 제작되었다. RFB 프로토콜은 내부에 디스플레이 프로토콜과 인풋 프로토콜을 가지고 있는 형태이며, 대부분의 원격제어 솔루션들이 사용하는 프로토콜들도 유사한 형태의 내부 프로토콜의 구분을 가지고 있다. 원격제어 솔루션의 사용보다 이러한 프로그램들의 구현에 관심이 있는 독자라면 VNC 홈페이지에서 개념정립에 도움이 될 문서들도 확인할 수 있을 것이다. 또 하나 참고로 리눅스, 유닉스, 솔라리스용 VNC의 설치와 설정은 터미널 모드에서 이루어지므로 설치 전 반드시 readme 문서를 확인하길 바란다. @

    출처 : Tong - firmware님의 갈곳없는것들 ㅠ.ㅠ통

    'Projects > CoVNC' 카테고리의 다른 글

    클립보드의 정의  (0) 2007.02.14
    Ultra VNC 소개  (0) 2007.02.13
    vnc 소개  (0) 2007.02.09
    Java DataFlavor를 이용한 클립보드 사용  (0) 2007.02.07
    DIB 형식 파일로 저장  (0) 2007.02.06
    DIB구조  (0) 2007.02.05

    댓글을 달아 주세요