虚拟终端[virtual terminal]开发计划

system888net

关注一下.

romandion

开发日志 :
版本历史    0.0.3  2008-12-20

1.    定义driver，负责解析TELNET协议，对外接口只提供需要执行的命令参数，和触发事件，还未实现，
      计划中，估计开发量会比较大。
      现在打算用SELECT来管理IO而不是POLL和EPOLL，性能应该不成问题，不过可以通用。

2.   命令管理层类似于文件系统的树型结构。

3.   执行框架ARCH启动后，将在一个线程中完成命令的执行［未来可能会使用进程，但现阶段只使用线程，
      简单］，管理命令由DRIVER负责触发，这样保证客户端的带外数据能被DRIVER接收被正确的传输到
      ARCH中，不会被执行过程所阻塞。

问题：
1.  没确定SELECT能否象EPOLL那样同时管理ACCEPT／READ／WRITE
2.  ARCH的执行线程  需要等待 新命令的到达，原来的libpr库没有这部分代码，需要添加

romandion

开发日志 :
版本历史    0.0.4  2008-12-24

1.  完成vtarch.c。当driver接收到数据后，按协议进行分析后，触发event_callback。vt_arch_event_callback根据事件
     类型对arch_thread进行操作。如果是pause/resume/quit等事件，由callback直接操作线程；如果是命令/数据/stop的
     话，生成消息，压入arch的消息队列。
2.  arch线程等待消息到来，否则阻塞在那边。
3.  封装pthread_cond_t，使用pthread_cond_wait来让消息读线程实现等待。
4.  pthread_cond_wait的时候会释放pthread_mutex_t，而获得pthread_cond_t本身的mutex。这个特点是最核心的本质。

问题：
1.  自行定义一个消息队列，2线程，一读一写。如何阻塞并保护消息队列，用简洁优美的办法。
2.  线程中执行一个函数，如vt_cmd_t。如何让他stop，就行用ctrl+c终止进程的执行。

romandion

开发日志：
2008-12-25

今天没有写代码，而是把telnet协议研究了下。发表在博客
http://blog.csdn.net/romandion/archive/2008/12/25/3606013.aspx
欢迎指教。

圣诞节快乐。

romandion

开发日志:
版本历史   0.0.6 2008-12-29
    现在开始做telnet驱动部分，本来想自己做一个，不过为了尽快拿出产品，决定先修改inetutils/telnet的源码，将
它拿过来用。关于telnet的协议细节在后面的版本将逐渐替换。

    呵呵，好像没什么人感兴趣，在第一个可用版本出来，我将终止在这个贴上发布开发日志，有兴趣的可以到google上
查看libevtd的开发进度，谢谢!

mirnshi

原帖由 romandion 于 2008-12-17 16:53 发表
在服务器或者许多没有终端界面的系统在调试下十分麻烦。想开发一个虚拟终端，DOS界面，可以集成到服务系统中，客户端可以通过telnet方面的调用。服务端库接口如下：

1.int vty_init(int port) ;

typedef  ...

貌似很简单的，就是一个socket服务端程序而已。要是做客户端，会麻烦一些，涉及到tty的一些东西。

romandion

貌似很简单的，就是一个socket服务端程序而已。要是做客户端，会麻烦一些，涉及到tty的一些东西。

如果只是一个服务端程序当然没有问题啊。不过要支持已经有的协议就比较麻烦了。如果要做好了，更麻烦了。如果你你有时间可以实现个telnet服务端看看就知道。

其实细节问题没有想的那么简单。呵呵，我自己做下来，还是要蛮东西要解决的。

mirnshi

我的理解是你想做一个支持远程telnet接口的库，利用库接口，远程通过命令串，执行相应的注册函数，用于获取或设置某些状态之类的。

这个库，不需要支持telnet协议吧。如同你可以telnet 25端口发送邮件，telnet 110查看邮件。是不是想复杂了

ttplay

其它人说做什么OS,我不相信,

不过redor应该可以做到, 因为这人的编码能力特强

romandion

原帖由 mirnshi 于 2008-12-29 17:07 发表

我的理解是你想做一个支持远程telnet接口的库，利用库接口，远程通过命令串，执行相应的注册函数，用于获取或设置某些状态之类的。

这个库，不需要支持telnet协议吧。如同你可以telnet 25端口发送邮件，teln ...

你的理解完全正确。

首先，客户端连接远程最常用的工具就是telnent/ssh之类的。所以支持这些协议有天生的优势。

其次，这些协议算是比较成熟的啊。支持他们比较容易使用。

如果支持私有协议，每次连接远程都需要启动自有的客户端。在使用上并不见得方便啊，除非你花大力气完善客户端。

假设有个开发人员使用这套库嵌入到自己的系统中，他通过telnet直接就可以使用，不是很好么？

实际上这个库的作用就是嵌入到其他daemon系统中。跟telnet25/110收发邮件不是一回事。你能为你的系统提供完善的调试工具么？类似于邮件系统。

我觉得这不一定是最好的，但很情况下就是简单、易用。