Photon——What's in Photon 3 Photon3是什么
What's in Photon 3 Photon3是什么
1. High Performance S2S API (Native/C++) 高性能的S2S API
A while back we introduced the TCPClient a managed class better suited for server to server communication than the standard client library. The TCPClient had two disadvantages: First the programming model on both ends of the connection was different (TCPClient on one side, peer on the other), second it was designed for low-bandwidth communication. With this release Photon can setup a connection to other Photon instances leveraging the networking power of the Photon Core while allowing to use the same programming model using peers on both ends of the connection.
不久前我们介绍了托管类TCPClient比标准客户端类库更适合于服务器到服务器的通信。这个TCPClient有两个缺点:第一，编程模型连接的两端都是不同的(TCPClient在一侧，peer在另一侧)，第二，是专为低带宽通信。这个版本的Photon可以设置一个连接其它Photon实例，利用Photon Core，同时允许peer在连接的两端使用相似的编程模型。
2. Load Balancing
负载均衡
With Photon Load Balancing, developers are enabled to create scalable multi-node solutions. It includes out of the box a master server hosting the lobby and game servers to host the active games. The Lite Lobby Application is delivered with a set of matchmaking methods and a load balancing component that distributes the load (where to create new games).
Photon负载均衡，开发人员能够创建可扩展的多节点的解决方案。它包括了一个主服务来托管大厅和多个游戏服务来托管游戏。这个Lite Lobby应用程序是通过设置配对方法和使用负载均衡组件分配负载来进行交付工作的。
3. Event Caching
事件缓存
So far, Lite had “Properties” for rooms and actors to store values for players who join later on. They are a nice idea but a bit clumsy to use: Whenever something has to be stored, you had to set properties. In all other cases, you send events.The new Lite Application combines both and gives you caching for events. Per player and event, you could cache the values in it. If anyone joins, the events are sent immediately, like they were just raised.
到目前为止，Lite用房间和玩家的属性为那些加入游戏之后的玩家来存储值。这是一个好主意，但是使用起来有点笨拙：无论什么东西被存储，您必须设置属性。在其他情况下，您发送事件。新的Lite应用程序结合了给予你的高速缓存事件。每个玩家和事件，您都可以缓存值在这里面。如果某人加入，立即发送事件，他们仅仅会被触发。
4. Extended Data Type Support
支持数据类型的扩展
Photon now supports more data-types than ever: Null values, dictionaries, arrays of objects (each with its own type) and even custom classes can be integrated and used in events.
Photon现在比以往任何时候都更加支持数据类型，例如：Null值、字典、数组对象(每个都有其自己的类型)和自定义被集成并用于事件里的类。
5. The Peer has new properties
Peer的新属性
NetworkProtocol, LocalIP, LocalPort.
6. Up to now you configured a global default application
为你配置一个全局的默认应用程序
Now it is also possible to define a default application per listener.
现在还可以定义一个默认的应用程序监听器。
Changed 改变
1. Lite and Lite Lobby Code-Cleanup
Lite和Lite Lobby代码清理
Event-, Operation- and Parameter-Codes are cleaned up. Everything was reassigned and the predefined codes should be out of your way now. There is an extra page which lists each old and new value.
事件、操作和参数编码被清理干净。 现在是一切重新分配和预定义的代码应该出现了。有一个额外的页面，其中列出了每个旧的和新的值。
2. Type of Codes
代码的类型
We decided to keep using bytes as type for codes. It’s just effective and lean. If needed, any operation or event could get sub-codes (not supported out of the box).The
ReturnCode
for operation responses was of type int. This is now short-typed. Not extremely lean. But short.
我们决定继续使用bytes作为代码的类型。这是有效的和精益的。如果需要，可以得到任何操作或事件的子码。这个ReturnCode对于操作响应是int类型的。这是短类型。不是非常精简，但是短。
3. Protocol Cleanup 协议清理
We cleaned up the protocol for Photon 3. This is next to invisible for you, but has some benefits. Most of all, the new protocol does no longer hard-code any codes. Any code for operations, results, parameters or events can be defined by your code.
我们为Photon3清理了协议。这对于你来说几乎是看不见的，但有一些好处。最重要的是用新的协议来做，不再需要硬编码任何代码。任何代码的操作、结果、 参数或事件可以根据你的代码来定义。
4. Error Handling
错误处理
The error handling was re-designed to
错误处理是被重新设计为
- always call the unhandled exception event handler
- it is no longer required to initialize the logging facade
- introduced three policies for unhandled exceptions: ignore, restart application, end process
- consistent behavior: before unhandled exceptions in threads controlled by Photon where logged and then ignored, those in other threads usually terminated the process.
- 总是调用未处理的异常事件处理
- 不再需要初始化 logging facade
- 对于未处理的异常有以下三个策略：忽略、 重启应用程序、终止进程
- 一致的行为：在线程通过Photon登录和忽略来控制未处理的异常之前，其他线程通常会终止这个进程。
Note: due to a bug in 2.6 sometimes exceptions where “transformed” into
ThreadAbortException or the application was unloaded without being loaded again (this is also fixed with 2.6.28).
注意:由于一个错误（在2.6）有时有例外，“transformed”到 ThreadAbortException 或应用程序被卸载不会再次被加载(这也是固定与2.6.28)。
5. Server SDK Changes (breaking) 服务器SDK改变（破坏）
- Peer classes are now required to inherit from class ‘PeerBase’. The former interface IPeer and class PhotonPeer were removed. Take a thorough look at the PeerBase class definition as it is a central piece of your application.
- Applications are now required to inherit from class ‘ApplicationBase’. Like PeerBase this is one of the most important classes.
- Classes ResponseParameterAttribute, RequestParameterAttribute and EventParameterAttribute have been substituted with class DataMemberAttribute. As a consequence, request and response parameters can not be part of the same container class anymore.
- The Params property of classes EventData, OperationRequest and OperatioResponse has been substituted wth the new property Parameters. This dictionary’s keys are now of type byte.
- The property EventData.EventCode has been renamed to ‘Code’ and its type was changed to byte.
- The type of the properties OperationRequest.OperationCode and OperationResponse.OperationCode has been changed to byte.
- The new class DataContract substitutes classes Operation and Event. While class Operation remains part of the framework it is not mandatory to use it in order to convert the parameters to class properties anymore.
- Methods Event.GetEventData and Operation.GetOperationResponse have been removed. Instead use the new OperationResponse and EventData constructors.
- PhotonPeer.SendBufferFull was removed. Override PeerBase.OnSendBufferFull to respond to a full send buffer. The counterpart PeerBase.OnSendBufferEmpty is called when Photon is ready to send more data.
- Peer类现在需要继承类自PeerBase。接口IPeer和类PhotonPeer IPeer被移除。把一个完整的PeerBase类的定义作为你应用程序的核心部分。
- 应用程序现在必须继承自类 ApplicationBase。像PeerBase这是其中一个最重要的类。
- 类 ResponseParameterAttribute 、 RequestParameterAttribute 和 EventParameterAttribute 被类DataMemberAttribute 代替。因此，请求和响应的参数不能属于同一个容器类了。
- 类 EventData , OperationRequest 和 OperatioResponse 的属性参数被新的属性参数代替。这本字典的键的类型是byte。
- 属性EventData.EventCode 已经改名为 “Code” 和它的类型改为byte。
- OperationRequest.OperationCode 和 OperationResponse.OperationCode 属性的类型已经变成了byte。
- 这个新类DataContract 替代了类 Operation 和 Event。虽然类的操作是framework的一部分，为了转换参数为类的属性它是不强制被使用的。
- 方法 Event.GetEventData 和 Operation.GetOperationResponse 已被移除。而使用新的 OperationResponse 和 EventData 构造函数。
- PhotonPeer.SendBufferFull 已被移除。覆盖 PeerBase.OnSendBufferFull 来响应一个完整的发送缓冲区。当Photon是准备好并发送更多的数据时这个 PeerBase.OnSendBufferEmpty 会被调用。
6. Client SDK Changes (breaking) 客户端SDK改变（破坏）
- renamed IPhotonListener interface member OperationResult to OnOperationResponse, EventAcion to OnEvent and PeerStatusCallback to OnStatusChanged.
- The different parameters of the old OperationResult (OperationCode, Parameters, …) are passed in one object OperationResponse. Same applies to OnEvent now has one parameter EventData.
- Support for invocation ID was removed.
- 更名IPhotonListener接口成员 OperationResult 为 OnOperationResponse 、 EventAcion 为 OnEvent 和 PeerStatusCallback 为 OnStatusChanged 。
- 旧的 OperationResult ( OperationCode , 参数 ,…)的不同参数被传递在一个 OperationResponse 对象里。同样适用于 OnEvent 有一个参数 EventData。
- 支持调用ID已被移除。
- PhotonHostRuntime version attribute was removed from the config file and is no longer required - we recommend to remove it to ease feature updates.
- The application NetSyncObjects is no longer part of the SDK.
- Changed default for dump files from mini to full
- Added version display to log file during start up.
- PhotonHostRuntime version属性已从配置文件中移除，和不再是必需的，我们建议删除它以便于功能更新。
- 应用程序NetSyncObjects不再是SDK的一部分。
- 改变转储文件的默认选项从迷你到全部。
- 添加版本显示到日志文件在启动的时候。
Bug Fixes Bug修复
- Fixed a memory leak when canceling actions scheduled on a fiber.
- S2S.TCPClient did not close the socket at disconnect which caused an error when calling Connect again.
- Flash policy file is claimed malformed with a top-level XML tag that is not, see http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html#_Malformed_Policy_Files
- Fixed CLR startup to ensure GC Server is used (issue affected .net 4.0 only).
- Fixed ENet fragmented buffering flow control bug.
- Fixed TCP magic byte issues - fragmented pings where not parsed correctly and an issue in the internal handling of the size of packets could lead to parsing errors (bigger packets and high load).
- Fixed Photon hang on shutdown trying to log on a dead logging instance.
- Fixed the method Peer GetRemoteAddress - due to a caching issue the result was wrong in some cases.
- Fixed mini dumps - now obey configured limits.
- Changed PhotonPeer::GetRemotePort so that it doesn’t rely on a cached port.
- 修正了当取消线程池的活动时内存的泄漏。
- S2S。 在断开的时候TCPClient没有关闭套接字，然后再次连接造成的一个错误。
- Flash策略文件被声称为畸形的最高等级的XML标记，其实它不是，看到 http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html #畸形的策略文件
- 修正了CLR启动时以确保GC服务器是可用的。
- 修正了eNet分散缓冲流控制的错误。
- 修正了TCP魔法字节问题——不正确的解析ping 和一个内部处理的问题，数据包的大小可能导致解析错误(更大的数据包和高负载)。
- 修正了Photon在关机时试图在一个关闭的日志实例进行记录。
- 修正了方法peer GetRemoteAddress ——由于缓存问题，在某些情况下结果错了。
- 修正迷你转储——现在服从配置的限制。
- 修改了 PhotonPeer::GetRemotePort ，因此，它不依赖于一个缓存的端口。