WARNING: The game isn't very interesting yet, because it's not done. Working on it as of September 2013.
NOTE: This works best with the Chrome browser. Firefox is super slow.
| Date: | |
| Time: | |
| Health: | |
| Energy: | |
| Travel: | |
| Terrain: | |
| Weather: | |
| Status: |
| Day | Time | Type | Text |
|---|
| Your name | |
| Date | |
| Time | |
| Crew size | |
| Average load | |
| Num crew sleepy | |
| Min crew energy | |
| Avg crew hunger | |
| Min crew health | |
| Avg crew health | |
| Travel mode | |
| Position | |
| Terrain | |
| Weather | |
| Version | |
| Status |
| name | gender | age | birthday | STR | DEX | INT | WIS | CHA | hours until sleepy | hunger | most recent meal | health | healing rate per day | physical energy | date joined crew | skills |
|---|
| Days survived | |
| Total gear value | |
| Cheater? |
This is a game of exploration, discovery, and adventure.
Try to survive as you build up your crew and gear. Can you discover the secret of the island?
To move around on the map, click it. You can click the little map or the big one. One click sends you in that direction for one hour.
Here are the technologies I used:


You've just created the MacWire + Akka example application! Let's explore what's inside.
The functionality of this console application is to calculate a lucky number basing on the user's age and favorite color.
The task is quite simple and the code is definitely too complicated for such a simple functionality, but it should serve demo purposes well.
There are two main parts: the calculator
module and the actors
module. We'll explore
each module in detail in the following sections, focusing on Dependency Injection, using
trait
s as modules, MacWire and integration with Akka.
To see how the application works, just Run it! There's no fancy UI, unless you consider the console to be fancy :).
Let's start exploring the code (open the sidebar to read the tutorial along with the code)!
The main class in the calculator package is the CalculateLuckyNumber class. It implements the main logic of actually computing the lucky number.
Note that the CalculateLuckyNumber
has two dependencies:
InterpretFavoriteColor
and RandomModifier
(as we all know, all lucky number computations are to some degree random). All of the classes are quite simple,
and in the end we simply add up all the numbers we get.
The fact that CalculateLuckyNumber
is dependent on InterpretFavoriteColor
and
RandomModifier
is expressed using a constructor parameter. And this is the main idea behind
Dependency Injection: instead of creating a specific implementation of e.g. an
InterpretFavoriteColor
inside the CalculateLuckyNumber
class using
new
, we only specify that we want "some" implementation. This decouples the two classes, as we
can now use any InterpretFavoriteColor
implementation, without the need to change
the code of the CalculateLuckyNumber
class.
The removal of creational concerns from the code leads to less code pollution and increased testability. Very often usage of Dependency Injection is accompanied by a framework, such as Guice or Spring. However, a framework is not required, and as this tutorial demonstrates, Scala language features can be used instead. Also, the mentioned frameworks most often rely on run-time reflection and hence provide less type safety. That said, they offer some advanced features which are not possible to achieve only with Scala/ MacWire. For a more detailed comparison, please refer to the materials mentioned at the end of the tutorial.
The calculator package also contains a CalculatorModule trait. In the trait we define how to create instances of the objects from this package.
In many cases we can just call new
with the right parameters to create the object graph. Note that
even when calling new
directly, we are doing Dependency Injection! The main point is that creating
the objects (object graph) is done separately from defining the classes. Here however, we are using MacWire
to remove a bit of the boilerplate that is associated with creating the instances.
The instances are defined using the wire
macro. A macro is a piece of Scala code which is
executed at compile time, generating Scala code. The code is then type-checked and further
compiled using standard rules. The wire
macro is part of the MacWire library.
The wire
macro will try to generate code to create a new instance of the given class, using as
parameters values found in the current scope. For example,
wire[CalculateLuckyNumber]
will expand to
new CalculateLuckyNumber(randomModifier,
interpretFavoriteColor)
Note that this is all done at compile-time - there's no run-time component here! At run-time, all the JVM
will see is new
invocation. And we get compile-time checking that all dependencies of a class
are satisfied!
Wiring using the macro can be useful when classes have several dependencies and enumerating all construction parameters would be tedious. Moreover the macro can be used only for some objects, others may be created by hand or using more complex custom code.
We use lazy val
s, so that we don't have to worry about initialization order. When using
val
s objects have to be defined prior to usage. This can lead to weird
NullPointerException
s, hence if possible just use lazy val
s or def
s.
In smaller applications we could define the wiring (how the object graph is constructed) in one trait/object for all packages, however as the codebase size grows, it can become hard to manage, hence splitting into several "modules" may be a good idea. The cake pattern takes this idea even further, putting also class definitions into the traits.
Note that creating such traits is entirely optional and is not a part of the "core" Dependency Injection pattern. It is simply a way of using Scala's traits to make the code more manageable, and the pattern easier to use.
The actors package contains three actors which are responsible for accepting user requests, calculating the lucky number and emailing it back to the user (well, email support will be available in 2.0, here we are just printing to the console).
CalculateRequest is
a simple data container which represents a user request. It is used by the
CalculateActor to
compute the lucky number and send it back to the sender. Note that the actor has a dependency - the service
we defined earlier in the calculator
package.
The EmailActor just prints outs any strings it get to the console. A much more interesting actor is the main one, EmailLuckyNumbersActor. That actor accepts requests, sends them to be calculated, and upon receiving a reply, emails the result.
There's a number of good ways to compose actors and pass around actor references; one quite widely used is
sending the ActorRef
s of collaborating actors in messages. Here, we are using another approach:
passing the ActorRef
as constructor parameters (dependencies). Both styles can be mixed of course,
depending on the specific use-case.
If you take a closer look at
EmailLuckyNumbersActor,
you'll notice that the dependencies have "tags", ActorRef @@ Calculate
and
ActorRef @@ Email
. The @@ T
part comes from MacWire, and is entirerly optional, but it
helps to differentiate which actor reference is which and gives some additional compile-time type checks; we
can only use properly tagged instances when passing parameters around.
The tags have no runtime overhead and the original idea comes from Miles Sabin and is also used e.g. in Scalaz.
Tags can be added to an instance using the .taggedWith[T]
method, which is available after importing
com.softwaremill.macwire._
. For example, we could tag an existing actor reference like this:
someActorRef.taggedWith[Email]
The tags are usually simple trait
s.
Just as with the calculator
module, there's also a trait-module for
To create actors, first of all we need to have access to a ActorSystem
. The module has an abstract
value of that type, which expresses a dependency of the module (which is a "level higher" than a dependency of
a single class). It also has another dependency, on a CalculateLuckyNumber
. Any usages of that
module will have to provide an implementation of these two values, and this will be enforced by the compiler.
Secondly, creating actors is a bit different then creating normal objects, as we have to wrap the actor-instance
creation code with actorSystem.actorOf(Props(...))
. As actors should be created with care, and we
probably only want them to be created explicitly, we are using def create...()
methods, instead of
values.
Note that we are tagging the email/calculate actors appropriately, and that creating the EmailLuckyNumbersActor
requires references to other actors being passed in. These actor references from method parameters will be
used when creating a EmailLuckyNumbersActor
instance.
The LuckyNumberDemo main class wraps all that we have done so far together.
First of all, we extend both modules we have defined: CalculatorModule
and
ActorsModule
. This brings into scope all of the values and methods defined. Note that also
the EmailLuckyNumbersActor
dependency from ActorsModule
is automatically satisfied
by the definition in CalculatorModule
(and of course, all of that is checked during compilation, using standard Scala mechanisms)!
The actor system dependency is not defined in any module hence we have to define it.
Secondly, we create the actors explicitly, passing around the right parameters. Thanks to tagging, we won't
be able to mix the email and calculator actor references when passing them to
createEmailLuckyNumbersActor
.
Finally, we calculate the result for some example data using our actor infrastructure!
Try yourself - just Run the code and enjoy dependency injection with plain Scala, Akka and MacWire!
A very important aspect of our application is testing. One of the main benefits of Dependency Injection is the ease with which you can test components in isolation, passing in alternative implementations of any of the class dependencies.
As an example, take a look at CalculateLuckyNumberTest. To be able to verify the behavior of the calculator, we need to substitute the random modifier which something that isn't random, e.g. returns a constant number.
Nothing easier! We just override the value from the module, and it will be used when wiring an instance of
CalculateLuckyNumber
!
What we have created is in fact an integration test of the whole module. We could have also created a new
CalculateLuckyNumber
instance directly and pass in either real or mock dependencies.
And that's it! We now have a simple Akka application, which uses Dependency Injection for wiring the services and actors.
The whole integration layer doesn't use reflection, only type-safe, compile-time code generation. And we're only using plain, old Scala traits and classes, without the help of any framework.
If you are interested, a couple of useful links:


Summoner Celestiel:
I hope you are taking care of my Arcana Card...
Are you still taking the Trial of the Summoner? If you defeat me and then lose to others I will be doubly disgraced. I pray you achieve straight victories and earn the Mark of the Summoner!


--- layout: default title: Resources - Wikimedia Security Team wmui_subnav: - href: /security-awareness/ text: Security Awareness - href: /handbook/ text: Team Handbook published: false ---
words words words


Handlers
publisherStartSpeaking (Session)
publisherStopSpeaking (Session)
publisherStartSpeaking (Publisher)
publisherStopSpeaking (Publisher)
streamAudioVolumeChange (Publisher)
publisherStartSpeaking (Subscriber)
publisherStopSpeaking (Subscriber)
streamAudioVolumeChange (Subscriber)


Buckley-James regression for right-censoring survival data with high-dimensional covariates. Implementations for survival data include boosting with componentwise linear least squares, componentwise smoothing splines, regression trees and MARS. Other high-dimensional tools include penalized regression for survival data.
| Version: | 0.2-3 |
| Depends: | R (≥ 2.10) |
| Imports: | mda, mpath, mboost, gbm, earth, elasticnet, rms, methods, modeltools, bst, parallel |
| Suggests: | TH.data, survival, R.rsp |
| Published: | 2017-04-27 |
| Author: | Zhu Wang and others (see COPYRIGHTS) |
| Maintainer: | Zhu Wang <zwang at connecticutchildrens.org> |
| License: | GPL-2 |
| Copyright: | see file COPYRIGHTS |
| NeedsCompilation: | no |
| Materials: | NEWS |
| In views: | Survival |
| CRAN checks: | bujar results |
| Reference manual: | bujar.pdf |
| Vignettes: |
Survival Prediction Using Gene Expression Data (Long) Survival Prediction Using Gene Expression Data (Short) |
| Package source: | bujar_0.2-3.tar.gz |
| Windows binaries: | r-devel: bujar_0.2-3.zip, r-release: bujar_0.2-3.zip, r-oldrel: bujar_0.2-3.zip |
| OS X binaries: | r-release: bujar_0.2-3.tgz, r-oldrel: bujar_0.2-3.tgz |
| Old sources: | bujar archive |
Please use the canonical form https://CRAN.R-project.org/package=bujar to link to this page.


Toggle navigation
{{ config.header || 'FeTSy-Hammertag' }}
Scan
List
Export
Import
Database
Signed in as {{ config.userName }}


Topic: Working from Home Success
Date:
Time: 9:00 AM - 1:00 PM
In this virtual event, we'll talk about success stories of work at home people. We'll discuss how did they get started, what are the needed tools, how much information or knowledge required to start, and many more.


Recently I purchased 6 EmonTH units without DHT22 sensors or 433MHZ Radios by accident, i added the components to them , but I am not receiving any inputs on the set node. Ive tried changing Node Etc, i have verified with the arduino software that they are loaded with V2.6 and set to 433MHZ Via RFM69CW's and I am able to see the values for Temp / Humidity and Battery Voltage via the serial monitor. I verified I have the emonPI updated to the latest available version , but still nothing. I thought perhaps there was a problem with the solder connections and i have inspected them visually with magnification , and i see no shorts/ errors with the installation(s).
Any advise / ideas here would be appreciated.
Thanks in advance.
Mike
Re: EmonTH with V2.6 and RFM69CW Programming help
Hello Mike, a couple of thoughts.
1. Are both the emonpi and emonth's on the same radio group and frequency, are the radio group and frequency settings in emonhub.conf on the emonPi the same? You can check this from the emonhub config editor in emoncms on your emonpi.
2. Perhaps the node decoders in emonhub.conf are incorrect leading to no nodes appearing in the emoncms nodes interface? The emonhub configuration guide here might help https://github.com/openenergymonitor/emonhub/blob/emon-pi/configuration.md
Do you see anything being received in the emonhub log? You can check the log again from within emoncms on your emonpi.
Re: EmonTH with V2.6 and RFM69CW Programming help
The firmware hex installed to a 868 emonTH is different to a 433 emonTH, having fitted your own rfm69 have you confirmed the right firmware is installed? does it confirm the frequency in the startup sequence over serial?
Whilst checking the group id, If you set "loglevel = DEBUG" in emonhub.conf and check the logs there should be some signs of packets arriving with node ids in the range 19 to 26, might take a while due to the emonTH's 60s intervals.
Unless there is a "fault" somewhere the most likely cause is that the emonpi was first used before the emonTH firmware included a "pulse" value and I believe the current emonPi update routine will not overwrite existing emonhub.conf entries. A quick check is to look for the word "pulse" on the end of the "names =" line in each emonth node in emonhub.conf [nodes], if it's not there you can either add the additional name, datacode, scale and unit for each node or just delete all your unused [nodes] entries and update the emonpi again it should pull in all the current node configurations.
Paul
Re: EmonTH with V2.6 and RFM69CW Programming help
after some experimenting / trial an error the problem appears to reside in the EmonTH(s) , i checked the emonhub and everything appears correct including the "pulse" . The EmonPI i am using is brand new and does show the local DS1820B Sensor plugged in / reporting data. I swapped it with another new EmonPI i had on hand and it does the same exact thing. Upon powering up a EmonTH purchased with the RFM69CW pre installed the data appeared in the proper node immediately. Im stumped.
The EmonTHs have V2.6 Firmware for 433 Mhz - and the RFM69s i purchased from the EMON online store so they should not be different.
Mike
Re: EmonTH with V2.6 and RFM69CW Programming help
What other serial printed info do you see when you have the programmer connected?
Does it complete the setup? does it print any values?
Paul
Re: EmonTH with V2.6 and RFM69CW Programming help
Paul ,
Here is a cut / paste of what the serial monitor shows for the EmonTH(s):
00
OpenEnergyMonitor.org
emonTH - Firmware V2.60
RFM69CW Init>
Node: 26 Freq: 433Mhz Network: 210
Detected DHT22
No DS18B20
DHT22 Temperature: 23.40C, DHT22 Humidity: 30.80%, Battery voltage: 3.00V, Pulse count: 1n
DHT22 Temperature: 23.50C, DHT22 Humidity: 29.90%, Battery voltage: 3.00V, Pulse count: 1n
Thanks,
Mike
Re: EmonTH with V2.6 and RFM69CW Programming help
That print seems to show all is in order that end, it doesn't directly confirm any data has been sent but the ongoing print tells us the code isn't getting stuck waiting for the rfm to respond as is usually the case with a rfm module fault. the serial stream is the equivalent of an led flash that would normally be assumed to mean the data was transmitted unless we can prove it definitely isn't being received at the other end.
Assuming we can rule out range etc, can you show us your emonhub.conf (obscure any wan apikeys)?
Paul
Re: EmonTH with V2.6 and RFM69CW Programming help
Paul ,
Below is the information you requested, but no lines have been edited from the original copy in either of the EmonPI units.
As far as distance goes they are both inside my home less than 20 feet apart so that can be ruled out .
#######################################################################
####################### emonhub.conf #########################
#######################################################################
###
### SPECIMEN emonHub configuration file
### Note that when installed from apt, a new config file is written
### by the debian/postinst script, so changing this file will do
### nothing in and of itself.
###
### Each Interfacer and each Reporter has
### - a [[name]]: a unique string
### - a type: the name of the class it instantiates
### - a set of init_settings (depends on the type)
### - a set of runtimesettings (depends on the type)
### Both init_settings and runtimesettings sections must be defined,
### even if empty. Init settings are used at initialization,
### and runtime settings are refreshed on a regular basis.
### Many settings below are "commented out" as they are not mandatory and
### have been included as a template or to provide alternative options
### removing the leading # will enable the setting and override the default
### Default settings are shown as comments on the same line as the setting
### eg #(default:xyz) "xyz" is set if the setting is "commented out".
###
### All lines beginning with '###' are comments and can be safely removed.
###
#######################################################################
####################### emonHub settings #######################
#######################################################################
[hub]
### loglevel must be one of DEBUG, INFO, WARNING, ERROR, and CRITICAL
### see here : http://docs.python.org/2/library/logging.html
loglevel = DEBUG #(default:WARNING)
#######################################################################
####################### Interfacers #######################
#######################################################################
[interfacers]
### This interfacer manages the RFM2Pi module
[[RFM2Pi]]
Type = EmonHubJeeInterfacer
[[[init_settings]]]
com_port = /dev/ttyAMA0
com_baud = 38400
[[[runtimesettings]]]
pubchannels = ToEmonCMS,
subchannels = ToRFM12,
# datacode = B #(default:h)
# scale = 100 #(default:1)
group = 210 #(default:210)
frequency = 433 #(default:433)
baseid = 5 #(emonPi default:5)
quiet = false #(default:true)
calibration = 230V #(UK/EU: 230V, US: 110V)
# interval = 300 #(default:0)
# nodeoffset = 32 #(default:0)
### This interfacer manages the RFM2Pi module
[[MQTT]]
Type = EmonHubMqttInterfacer
[[[init_settings]]]
mqtt_host = <IP_ADDRESS>
mqtt_port = 1883
mqtt_user = emonpi
mqtt_passwd = emonpimqtt2016
[[[runtimesettings]]]
pubchannels = ToRFM12,
subchannels = ToEmonCMS,
basetopic = emonhub/
[[emoncmsorg]]
Type = EmonHubEmoncmsHTTPInterfacer
[[[init_settings]]]
[[[runtimesettings]]]
pubchannels = ToRFM12,
subchannels = ToEmonCMS,
url = http://emoncms.org
apikey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
senddata = 1
sendstatus = 1
#######################################################################
####################### Nodes #######################
#######################################################################
[nodes]
### List of nodes by node ID
### 'datacode' is default for node and 'datacodes' are per value data codes.
### if both are present 'datacode' is ignored in favour of 'datacodes'
### eg node 99 would expect 1 long and 4 ints, unless the "datacodes" line
### was removed, then "datacode" would make it expect any number of longs,
### likewise per value "scales" will override default node "scale", the number
### of "scales" must match the number of values or frame will be discarded.
[[5]]
nodename = emonPi
firmware = emonPi_RFM69CW_RF12Demo_DiscreteSampling.ino
hardware = emonpi
[[[rx]]]
names = power1,power2,power1_plus_power2,Vrms,T1,T2,T3,T4,T5,T6,pulseCount
datacodes = h, h, h, h, h, h, h, h, h, h, L
scales = 1,1,1,0.01,0.1,0.1,0.1,0.1,0.1,0.1,1
units = W,W,W,V,C,C,C,C,C,C,p
[[19]]
nodename = emonTH_1
firmware = emonTH_DHT22_DS18B20_RFM69CW
hardware = emonTH_(Node_ID_Switch_DIP1:OFF_DIP2:OFF)
[[[rx]]]
names = temperature, external temperature, humidity, battery
datacode = h
scales = 0.1,0.1,0.1,0.1
units = C,C,%,V
[[20]]
nodename = emonTH_2
firmware = emonTH_DHT22_DS18B20_RFM69CW
hardware = emonTH_(Node_ID_Switch_DIP1:ON_DIP2:OFF)
[[[rx]]]
names = temperature, external temperature, humidity, battery
datacode = h
scales = 0.1,0.1,0.1,0.1
units = C,C,%,V
[[21]]
nodename = emonTH_3
firmware = emonTH_DHT22_DS18B20_RFM69CW
hardware = emonTH_(Node_ID_Switch_DIP1:OFF_DIP2:ON)
[[[rx]]]
names = temperature, external temperature, humidity, battery
datacode = h
scales = 0.1,0.1,0.1,0.1
units = C,C,%,V
[[22]]
nodename = emonTH_4
firmware = V1_5_emonTH_DHT22_DS18B20_RFM69CW
hardware = emonTH_(Node_ID_Switch_DIP1:ON_DIP2:ON)
[[[rx]]]
names = temperature, external temperature, humidity, battery
datacode = h
scales = 0.1,0.1,0.1,0.1
units = C,C,%,V
[[10]]
nodename = emonTx_1
firmware =V1_6_emonTxV3_4_DiscreteSampling
hardware = emonTx_(NodeID_DIP_Switch1:OFF)
[[[rx]]]
names = power1, power2, power3, power4, Vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse #Firmware V1.6
#names = power1, power2, power3, power4, Vrms, temp #Firmware =<V1.4 (un-comment)
datacode = h
scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1,1 #Firmware V1.6
units =W,W,W,W,V,C,C,C,C,C,C,p #FirmwareV1.6
#scales = 1,1,1,1,0.01,0.1 #Firmware =<V1.4 (un-comment)
#units =W,W,W,W,V,C #Firmware =<V1.4 (un-comment)
[[9]]
nodename = emonTx_2
firmware =V1_6_emonTxV3_4_DiscreteSampling
hardware = emonTx_(NodeID_DIP_Switch1:ON)
[[[rx]]]
names = power1, power2, power3, power4, Vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse #Firmware V1.6
#names = power1, power2, power3, power4, Vrms, temp #Firmware =<V1.4 (un-comment)
datacode = h
scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1,1 #Firmware V1.6
units =W,W,W,W,V,C,C,C,C,C,C,p #FirmwareV1.6
#scales = 1,1,1,1,0.01,0.1 #Firmware =<V1.4 (un-comment)
#units =W,W,W,W,V,C #Firmware =<V1.4 (un-comment)
[[6]]
nodename = emonTxShield
firmware =emonTxShield
hardware = emonTxShield
[[[rx]]]
names = power1, power2, power3, power4, Vrms
datacode = h
scales = 1,1,1,1,0.01
units =W,W,W,W,V
[[23]]
nodename = emonTH_5
firmware = V2.x_emonTH_DHT22_DS18B20_RFM69CW_Pulse
hardware = emonTH_(Node_ID_Switch_DIP1:OFF_DIP2:OFF)
[[[rx]]]
names = temperature, external temperature, humidity, battery, pulseCount
datacodes = h,h,h,h,L
scales = 0.1,0.1,0.1,0.1,1
units = C,C,%,V,p
[[24]]
nodename = emonTH_6
firmware = V2.x_emonTH_DHT22_DS18B20_RFM69CW_Pulse
hardware = emonTH_(Node_ID_Switch_DIP1:ON_DIP2:OFF)
[[[rx]]]
names = temperature, external temperature, humidity, battery, pulseCount
datacodes = h,h,h,h,L
scales = 0.1,0.1,0.1,0.1,1
units = C,C,%,V,p
[[25]]
nodename = emonTH_7
firmware = V2.x_emonTH_DHT22_DS18B20_RFM69CW_Pulse
hardware = emonTH_(Node_ID_Switch_DIP1:OFF_DIP2:ON)
[[[rx]]]
names = temperature, external temperature, humidity, battery, pulseCount
datacodes = h,h,h,h,L
scales = 0.1,0.1,0.1,0.1,1
units = C,C,%,V,p
[[26]]
nodename = emonTH_8
firmware = V2.x_emonTH_DHT22_DS18B20_RFM69CW_Pulse
hardware = emonTH_(Node_ID_Switch_DIP1:ON_DIP2:ON)
[[[rx]]]
names = temperature, external temperature, humidity, battery, pulseCount
datacodes = h,h,h,h,L
scales = 0.1,0.1,0.1,0.1,1
units = C,C,%,V,p
[[8]]
nodename = emonTx_3
firmware =V2_3_emonTxV3_4_DiscreteSampling
hardware = emonTx_(NodeID_DIP_Switch1:OFF)
[[[rx]]]
names = power1, power2, power3, power4, Vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
datacodes = h,h,h,h,h,h,h,h,h,h,h,L
scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1,1
units =W,W,W,W,V,C,C,C,C,C,C,p
[[7]]
nodename = emonTx_4
firmware =V2_3_emonTxV3_4_DiscreteSampling
hardware = emonTx_(NodeID_DIP_Switch1:OFF)
[[[rx]]]
names = power1, power2, power3, power4, Vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
datacodes = h,h,h,h,h,h,h,h,h,h,h,L
scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1,1
units =W,W,W,W,V,C,C,C,C,C,C,p
Re: EmonTH with V2.6 and RFM69CW Programming help
Aha!
The external temperature sensor appears to be missing from the serial print, this doesn't tell us whether it is in the rf transmission or not though.
You could try
[[26]]
nodename = emonTH_8
firmware = V2.x_emonTH_DHT22_DS18B20_RFM69CW_Pulse
hardware = emonTH_(Node_ID_Switch_DIP1:ON_DIP2:ON)
[[[rx]]]
names = temperature, humidity, battery, pulseCount
datacodes = h,h,h,L
scales = 0.1,0.1,0.1,1
units = C,%,V,p
in place of your [[26]]
or if that doesn't work attach an emonhub.log that lasts at least a few minutes.
Paul
Re: EmonTH with V2.6 and RFM69CW Programming help
Paul ,
Attached is a copy of the file , shows nothing for node 26 only node 5 that the unit purchased with a preinstalled radio is set for.
Mike
Re: EmonTH with V2.6 and RFM69CW Programming help
I think we need a longer log than that - there is only 10 s there. The emonTx only transmits once every 5 minutes.
Re: EmonTH with V2.6 and RFM69CW Programming help
Attached is the full file compressed , the input i am looking for is from an EmonTH not a Tx
Mike
Re: EmonTH with V2.6 and RFM69CW Programming help
[Paul - pb66 - has been very busy at work recently, it might be a little while before he can look at your data and respond.]
I can see input from node 23 at 2016-02-27 12:37:03,123, at 12:38:03,505, at 12:39:03,824 and every minute after, so the TH is definitely transmitting and emonHub is definitely seeing it. It's sending 12 bytes, so the original Node definition should be correct, and indeed appears to be so, as it looks as if the data is being handled (but Paul must confirm this).
That's about the limit of my knowledge I'm afraid.
Re: EmonTH with V2.6 and RFM69CW Programming help
Yes, my apologies for not answering sooner. I've not been about much at all.
I do hope you have resolved this, it looks like Node 23 is performing as expected, but there are no signs of 26. If you only had the one node working, then the probability is the node was not set as expected, I think nodes 23 and 26 switch positions would be the same but inverted, so it's easily done.
If you did have both 23 and 26 running, then it would appear the node 26 device itself is probably at fault, as 23 proves the receiver etc is all good.
Paul
Re: EmonTH with V2.6 and RFM69CW Programming help
Paul ,
Yes I did have both running , and I am positive i had the switches correct , as I mentioned previously i have six units that perform the same way. No input shows on the Emonpi.
Mike
Re: EmonTH with V2.6 and RFM69CW Programming help
"as I mentioned previously i have six units that perform the same way"
Do they all perform the same?
You mention you have 6 units that you have fitted rfm modules to, you then say you are not getting any inputs and continue to discuss node "26". You provided a log and explained "shows nothing for node 26 only node 5" closer examination showed node "23" working. it was quite reasonable to assume "23" might be the missing "26" since there was no mention of "23". Does "Yes I did have both running" mean you have just 2 running or are all 6 running?
Thrown by the statment about them being all the same but "23" and "26" are clearly different I have re read the thread and reminded of a 7th emonTH, presumablly this is "23" ?.
the fact "23" works proves the reciever works and that emonhub is processing the packets recieved. It does look like the modules are incorrect or incorrectly fitted, I doubt all 6 could be incoreectly fitted in the same manner unless orientated 180degs out and I'm guessing you will have already visually compared the working unit to the non-working units, plus I would of expected the firmware to hang if the rfm modules were not responding at runtime.
I now wonder if the modules you have fitted are 868 as they could be configured to act as 433 modules but the physical chariteristics (antenna length and componant values) would prevent them from working "effectively" at 433, they would probally have a range extending just a few centimetres (if at all). this could explain why the firmware doesn't halt and yet no packets are recieved.
Can you provide (links to) Hi res pics of a failed device's rfm module? (2mb limit on this site)
I think the best way for you to move forward with this is to install the rfm2pi firmware to an emonTH to create an independent test transciever,
If installed to the known good "23" emonTH the quiet mode can be switched off to see the flow of any unsuccesfully decoded packets that are recieved, (this function is not available on the emonpi).
Alternatively or additionally you can Install the firmware to a suspect (868?) emonTH to see if you are getting any transmissions after setting one of the other suspect emonTH's settings to 868MHz also,
If you do try this don't use the existing hex files as they are compiled for a 8MHz device (rfm2pi has no ext xtal) just open the firmware in Arduino IDE and "upload" direct to emonTH via usb programmer as a "uno" type 16MHz device.
Paul
[There are pictures identifying the various radio modules in Resources > Building Blocks. (RW)]


Kinetics of point masses
Newton's equations
Newton's equations relate the acceleration $\vec{a}$ of a point mass with mass $m$ to the total applied force $\vec{F}$ on the mass (sum of all applied forces). They are:
Newton's equations.
\[\vec{F} = m \vec{a}\]
There is no derivation for Newton's equations, because they are an assumed model for dynamics. We can only verify them by comparing with experimental evidence, which confirms that Newtonian dynamics are accurate for non-relativistic and non-quantum systems.
Click and hold on the figure to apply a constant-magnitude force.
A point mass moving in the plane with an applied force. You can try to made the mass move in a circle and then see what happens when the force is suddenly removed, which will demonstrate Newton's first law (no net force implies motion at constant speed in a constant direction). Also observe which force directions cause the speed to increase or decrease.
If we have objects which are either very massive, very small, or moving very fast, then Newton's equations do not provide a good model of their motion. Instead we must use Einstein's equations of general relativity (for massive and fast objects) or the equations of quantum mechanics (for very small objects). Unfortunately, these two theories cannot be used together, so we currently have no good models for objects which are simultaneously very small and very massive, such as micro black holes or the universe shortly after the big bang. Physicists are currently trying to reconcile general relativity with quantum mechanics by devising a new set of equations (sometimes called quantum gravity or a theory of everything). Current possibilities for new equations include string theory and loop quantum gravity, but none of these are generally accepted yet.
It is important to remember that all of these different equations are only models of reality and are not actually real:
“All models are wrong. Some models are useful.”
— George Box
Method of assumed forces and method of assumed motion
Newton's equations can be used in two main ways. Either we know the forces and we use this to compute the acceleration of a mass, or we know the acceleration and use this to compute the forces.
| Method of assumed forces: | Know $\vec{F}$ | $\Longrightarrow$ | Compute $\vec{a}$ |
|---|---|---|---|
| Method of assumed motion: | Know $\vec{a}$ | $\Longrightarrow$ | Compute $\vec{F}$ |
Of course there are other possibilities from these two, such as knowing the vertical component of the force and the horizontal component of acceleration, and then computing the missing components of each.
Example Problem: Method of assumed forces
A cannonball of mass $m$ is fired from the origin with initial velocity $\vec{v}_0$ and then experiences a force $\vec{F}_{\rm g} = -m g \hat{\jmath}$ due to gravity and a wind force $\vec{F}_{\rm w} = -C_{\rm w} \hat{\imath}$. What is the motion of the cannonball as a function of time?
We can use Newton's equations to find the acceleration of the cannonball, using the method of assumed forces: \[\begin{aligned} m \vec{a} &= \vec{F}_{\rm w} + \vec{F}_{\rm g} \\ \vec{a} &= \frac{1}{m} \left( - C_{\rm w} \hat{\imath} - m g \hat{\jmath} \right) \end{aligned}\]
If $\vec{r}$ is the position vector of the cannonball then we have the differential equation: \[\begin{aligned} \ddot{\vec{r}}(t) &= - \frac{C_{\rm w}}{m} \hat{\imath} - g \hat{\jmath} & \vec{r}(0) &= \vec{0} & \dot{\vec{r}}(0) &= \vec{v}_0. \end{aligned}\] Because the acceleration is constant we can use the elementary motion solution to find the trajectory of the cannonball: \[ \vec{r}(t) = \vec{v}_0 t - \frac{1}{2} t^2 \left(\frac{C_{\rm w}}{m} \hat{\imath} + g \hat{\jmath}\right). \]
Example Problem: Method of assumed motion
A car of mass $m$ is observed driving on a sinusoidal road at a constant horizontal speed $v_0$. The road surface has equation $y = A \sin(k x)$, where $A$ is the amplitude and $k$ is the wavenumber. What is the force of the road on the car? Gravity $g$ acts vertically and assume no air resistance.
We can determine the acceleration of the car, and then use Newton's equations and method of assumed motion to find the total force and thus the road force. First, we find the acceleration: \[\begin{aligned} x(t) &= x_0 + v_0 t \\ \vec{r}(t) &= x(t)\,\hat{\imath} + y(x(t))\,\hat{\jmath} \\ &= (x_0 + v_0 t)\,\hat{\imath} + A \sin(k x_0 + k v_0 t)\,\hat{\jmath} \\ \vec{a}(t) = \ddot{\vec{r}}(t) &= - A (k v_0)^2 \sin(k x_0 + k v_0 t)\,\hat{\jmath} \\ &= - A (k v_0)^2 \sin(k x)\,\hat{\jmath}. \end{aligned}\] Given the force of gravity $\vec{F}_{\rm g} = - m g \,\hat{\jmath}$ and the road force $\vec{F}_{\rm r}$, Newton's equations give the forces as: \[\begin{aligned} \vec{F}_{\rm r} + \vec{F}_{\rm g} &= m \vec{a} \\ \vec{F}_{\rm r} &= - m A (k v_0)^2 \sin(k x)\,\hat{\jmath} + m g \,\hat{\jmath} \\ &= m \Big(g - A (k v_0)^2 \sin(k x)\Big) \,\hat{\jmath}, \end{aligned}\] where we have solved for the road force on the car.
The steps involved in analyzing a mechanical system with Newton's equations are as follows.
Solution procedure with Newton's equations.
\[\begin{aligned} &\text{1. FBD: draw a Free Body Diagram.} \\ &\text{2. Kinematics: determine $\vec{a}$.} \\ &\text{3. Newton: use $\vec{F} = m\vec{a}$.} \\ &\text{4. Algebra: rearrange and solve as needed.} \end{aligned}\]
Example Problem: Pendulum with Newton's equations
Consider the 2D pendulum with a massless rigid rod of length $\ell$ and a point mass $m$. What is the equation of motion for $\ddot\theta$ and the tension $T$ in the rod?
It is helpful in this problem to use both Cartesian and polar bases:
1. FBD: The free body diagram for the point mass is:
The forces on the free body diagram are: \[\begin{aligned} \vec{F}_g &= - mg \,\hat\jmath \\ \vec{F}_T &= - T \,\hat{e}_r. \end{aligned}\]
2. Kinematics: Using the polar basis acceleration equation #rkv-ep gives: \[\begin{aligned} \vec{a} &= (\ddot{r} - r\dot\theta^2) \,\hat{e}_r + (r\ddot\theta + 2\dot{r}\dot\theta) \,\hat{e}_\theta \\ &= -\ell \dot\theta^2 \,\hat{e}_r + \ell\ddot\theta \,\hat{e}_\theta. \end{aligned}\]
3. Newton: Using #rep-en gives: \[\begin{aligned} \vec{F} &= m\vec{a} \\ \vec{F}_T + \vec{F}_g &= m(-\ell \dot\theta^2 \,\hat{e}_r + \ell\ddot\theta \,\hat{e}_\theta) \\ -T\,\hat{e}_r - mg\,\hat\jmath &= -m\ell \dot\theta^2 \,\hat{e}_r + m\ell\ddot\theta \,\hat{e}_\theta. \end{aligned}\]
4. Algebra: To compare components in the above equation we need to switch to a single basis. We will convert to $\hat{e}_r,\hat{e}_\theta$ using: \[ \hat\jmath = -\cos\theta \,\hat{e}_r + \sin\theta \,\hat{e}_\theta, \] which gives: \[ (-T + mg\cos\theta)\,\hat{e}_r - mg\sin\theta\,\hat{e}_\theta = -m\ell \dot\theta^2 \,\hat{e}_r + m\ell\ddot\theta \,\hat{e}_\theta. \] Equating the $\hat{e}_\theta$ and $\hat{e}_r$ terms gives $\ddot\theta$ and $T$ by: \[\begin{aligned} \ddot\theta &= - \frac{g}{\ell} \sin\theta \\ T &= mg\cos\theta + m\ell\dot\theta^2. \end{aligned}\]
Newton's equations $\vec{F} = m\vec{a}$ are an algebraic expression of Newton's second law:
“Mutationem‑mutation/change
motûs‑motion
proportionalem‑proportional
esse‑is
vi‑force
motrici‑motive
impressæ‑impressed/applied,
et‑and
fieri‑is
secundum‑along
lineam‑line
rectam‑right/straight
quâ‑which
vis‑force
illa‑that
imprimitur‑imprints/acts.”
—
Isaac Newton,
Principia, 1687.
“The change of motion is proportional to the applied force, and takes place in the direction of the straight line in which the force acts.”
Although Newton was English and lived in England, he wrote the Principia in Latin because that was the standard language for scientific communication at the time. By the late 1600s the use of Latin was in decline, however, and Newton's later works, such as Opticks in 1704, were written in English.
Linear momentum
The linear momentum of a point mass is the product of its mass and velocity:
Linear momentum of a point mass.
\[\vec{p} = m\vec{v}\]
Using the linear momentum, Newton's equations are:
Newton's equations in momentum form.
\[\vec{F} = \dot{\vec{p}}\]
If we differentiate the linear momentum with respect to time then we obtain \[\frac{d}{dt} \vec{p} = \frac{d}{dt} (m \vec{v}) = m \dot{\vec{v}} = m \vec{a} = \vec{F}. \]
Warning: Variable mass problems can't simply use $\vec{F} = \dot{\vec{p}}$.
For a system with variable mass, such as a rocket burning up its fuel, it is tempting to write \[\vec{F} = \dot{\vec{p}} = \frac{d}{dt} (m \vec{v}) = \dot{m} \vec{v} + m \dot{\vec{v}}\] and to then rearrange to find the acceleration: \[m \vec{a} = \vec{F} - \dot{m} \vec{v}.\] But this is wrong! The acceleration must depend not only on the rate of mass loss, but also on the speed with which the lost mass is ejected.
The right way to calculate the acceleration of a rocket is to consider the center of mass of the total system (rocket plus ejected mass) and to use the equation for the center of mass of a many-body system. This results in the Tsiolkovsky rocket equation: \[m \vec{a} = \vec{v}_{\rm e} \dot{m},\] where the acceleration $\vec{a}$ of the rocket is determined by the rate of mass loss $\dot{m}$ and the velocity $\vec{v}_{\rm e}$ of the ejected mass relative to the rocket.
Angular momentum
Angular momentum is defined with respect to a given base point $O$. For a point mass, the angular momentum is the cross product between the position vector and the linear momentum:
Angular momentum about fixed base point $O$ of a point mass at $P$.
\[\vec{H}_O = \vec{r}_{OP} \times \vec{p}_P = \vec{r}_{OP} \times m\vec{v}_P\]
When a force is applied to a body it produces a moment about any given fixed base point $O$:
Moment about fixed point $O$ of a force acting at $P$.
\[\vec{M}_O = \vec{r}_{OP} \times \vec{F}_P\]
The angular momentum and applied moment are related by:
Moment equation about fixed base point $O$.
\[\vec{M}_O = \dot{\vec{H}}_O\]
If we compute the derivative of $\vec{H}_O$ and use Newton's equations #rep-en, then we obtain: \[\begin{aligned} \dot{\vec{H}}_O &= \frac{d}{dt} \Big( \vec{r}_{OP} \times m \vec{v}_P \Big) \\ &= \dot{\vec{r}}_{OP} \times m \vec{v}_P + \vec{r}_{OP} \times m \dot{\vec{v}}_P \\ &= m \vec{v}_P \times \vec{v}_P + \vec{r}_{OP} \times m \vec{a}_P \\ &= 0 + \vec{r}_{OP} \times \vec{F} \\ &= \vec{M}_O. \end{aligned}\] Here we used the fact that, for a fixed point $O$, the derivative $\dot{\vec{r}}_{OP}$ is simply the velocity $\vec{v}_P$ of point $P$, and the cross product of the velocity with itself is zero.
Warning: Always indicate the base point for angular momentum and moments.
In the moment equation #rep-et it is crucial that $\vec{M}_O$ and $\vec{H}_O$ are both computed about the same base point $O$. If we have $\vec{M}_O$ about $O$ and $\vec{H}_C$ about $C$, then it is not true that $\vec{M}_O = \dot{\vec{H}}_C$. For this reason we always write the base point $O$ as a subscript on $M$ and $H$, otherwise it's easy to forget which point we've used as the base point.


Use JTA global transactions to coordinate Geode cache transactions and JDBC transactions.
JTA is a standard Java interface you can use to coordinate Geode cache transactions and JDBC transactions globally under one umbrella. JTA provides direct coordination between the Geode cache and another transactional resource, such as a database. The parties involved in a JTA transaction include:
- The Java application, responsible for starting the global transaction
- The JTA transaction manager, responsible for opening, committing, and rolling back transactions
- The transaction resource managers, including the Geode cache transaction manager and the JDBC resource manager, responsible for managing operations in the cache and database respectively
Using JTA, your application controls all transactions in the same standard way, whether the transactions act on the Geode cache, a JDBC resource, or both together. When a JTA global transaction is done, the Geode transaction and the database transaction are both complete.
When using JTA global transactions with Geode, you have three options:
- Coordinate with an external JTA transaction manager in a container (such as WebLogic or JBoss)
- Set Geode as the “last resource” while using a container (such as WebLogic or JBoss) as the JTA transaction manager
- Have Geode act as the JTA transaction manager
An application creates a global transaction by using javax.transaction.UserTransaction
bound to the JNDI context java:/UserTransaction
to start and terminate transactions. During the transaction, cache operations are done through Geode as usual as described in Geode Cache Transactions.
Note:
See the Sun documentation for more information on topics such as JTA, javax.transaction
, committing and rolling back global transactions, and the related exceptions.
Coordinating with External JTA Transactions Managers
Geode can work with the JTA transaction managers of several containers like JBoss, WebLogic, GlassFish, and so on.
Using Geode as the “Last Resource” in a Container-Managed JTA Transaction
The “last resource” feature in certain 3rd party containers such as WebLogic allow the use one non-XAResource (such as Geode) in a transaction with multiple XAResources while ensuring consistency.
Using Geode as the JTA Transaction Manager
You can also use Geode as the JTA transaction manager.
Behavior of Geode Cache Writers and Loaders Under JTA
When Geode participates in a global transactions, you can still have Geode cache writers and cache loaders operating in the usual way.
-
You can configure regions to not participate in any JTA global transaction.
Coordinating with External JTA Transactions Managers
Geode can work with the JTA transaction managers of several containers like JBoss, WebLogic, GlassFish, and so on.
At startup Geode looks for a TransactionManager (javax.transaction.TransactionManager
) that has been bound to its JNDI context. When Geode finds such an external transaction manager, all Geode region operations (such as get and put) will participate in global transactions hosted by this external JTA transaction manager.
This figure shows the high-level operation of a JTA global transaction whose resources include a Geode cache and a database.
An externally coordinated JTA global transaction is run in the following manner:
- Each region operation looks up for presence of a global transaction. If one is detected, then a Geode transaction is started automatically, and we register a
javax.transaction.Synchronization
callback with the external JTA transaction manager. - At transaction commit, Geode gets a
beforeCommit()
callback from the external JTA transaction manager. Geode does all locking and conflict detection at this time. If this fails, an exception is thrown back to JTA transaction manager, which then aborts the transaction. - After a successful
beforeCommit()
callback, JTA transaction manager asks other data sources to commit their transaction. - Geode then gets a
afterCommit()
callback in which changes are applied to the cache and distributed to other members.
You can disable JTA in any region that should not participate in JTA transactions. See Turning Off JTA Transactions.
How to Run a JTA Transaction Coordinated by an External Transaction Manager
Use the following procedure to run a Geode global JTA transaction coordinated by an external JTA transaction manager.
- Configure the external data sources in the external container. Do not configure the data sources in cache.xml . They are not guaranteed to get bound to the JNDI tree.
Configure Geode for any necessary transactional behavior in the
cache.xml
file. For example, enablecopy-on-read
and specify a transaction listener, as needed. See Setting Global Copy on Read and Configuring Transaction Plug-In Event Handlers for details.Make sure that JTA transactions are enabled for the regions that will participate in the transaction. See Turning Off JTA Transactions for details.
Start the transaction through the external container.
Initialize the Geode cache. Geode will automatically join the transaction.
Execute operations in the cache and the database as usual.
Commit the transaction through the external container.
Using Geode as the “Last Resource” in a Container-Managed JTA Transaction
The “last resource” feature in certain 3rd party containers such as WebLogic allow the use one non-XAResource (such as Geode) in a transaction with multiple XAResources while ensuring consistency.
In the previous two JTA transaction use cases, if the Geode member fails after the other data sources commit but before Geode receives the afterCommit
callback, Geode and the other data sources may become inconsistent. To prevent this from occurring, you can use the container’s “last resource optimization” feature, with Geode set as the “last resource”. Using Geode as the last resource ensures that in the event of failure, Geode remains consistent with the other XAResources involved in the transaction.
To accomplish this, the application server container must use a JCA Resource Adapter to accomodate Geode as the transaction’s last resource. The transaction manager of the container first issues a “prepare” message to the participating XAResources. If the XAResources all accept the transaction, then the manager issues a “commit” instruction to the non-XAResource (in this case, Geode). The non-XAResource (in this case, Geode) participates as a local transaction resource. If the non-XAResource fails, then the transaction manager can rollback the XAResources.
How to Run JTA Transactions with Geode as a “Last Resource”
- Locate the version-specific
geode-jca
RAR file within thelib
directory of your Geode installation. Add your container-specific XML file to the
geode-jca
RAR file.- Create a container-specific resource adapter XML file named <container>-ra.xml. For example, an XML file for a WebLogic resource adapter XML file might look something like this:
<?xml version="1.0"?> <!DOCTYPE weblogic-connection-factory-dd PUBLIC '-//BEA Systems, Inc.//DTD WebLogic 9.0.0 Connector//EN' 'http://www.bea.com/servers/wls810/dtd/weblogic810-ra.dtd'> <weblogic-connection-factory-dd> <connection-factory-name>GFE JCA</connection-factory-name> <jndi-name>gfe/jca</jndi-name> </weblogic-connection-factory-dd>
- Create a folder named
META-INF
, and place the container-specific XML file inside the directory. For example, the folder structure would look like this:META-INF/weblogic-ra.xml
- Navigate to the directory above the
META-INF
folder and execute the following command, with appropriate substitutions for path and file names:$ jar -uf /path/to/lib/geode-jca-X-X-X.rar META-INF/weblogic-ra.xml
- Create a container-specific resource adapter XML file named <container>-ra.xml. For example, an XML file for a WebLogic resource adapter XML file might look something like this:
Make sure that the
geode-dependencies.jar
is accessible in the CLASSPATH of the JTA transaction coordinator container.Deploy the version-specific
geode-jca
RAR file on the JTA transaction coordinator container. When deploying the file, you specify the JNDI name and so on.Configure Geode for any necessary transactional behavior. Enable
copy-on-read
and specify a transaction listener, if you need one. See Setting Global Copy on Read and Configuring Transaction Plug-In Event Handlers for details.Get an initial context through
org.apache.geode.cache.GemFireCache.getJNDIContext
. For example:Context ctx = cache.getJNDIContext();
This returns
javax.naming.Context
and gives you the JNDI associated with the cache. The context contains theTransactionManager
,UserTransaction
, and any configured JDBC resource manager.Start and commit the global transaction using the
UserTransaction
object rather than with Geode’sCacheTransactionManager
.UserTransaction txManager = (UserTransaction)ctx.lookup("java:/UserTransaction");
Obtain a Geode connection.
GFConnectionFactory cf = (GFConnectionFactory) ctx.lookup("gfe/jca"); //This step of obtaining connection is what begins the //LocalTransaction. //If this is absent, GFE operations will not be part of any //transaction GFConnection gemfireConn = (GFConnection)cf.getConnection();
See JCA Resource Adapter Example for an example of how to set up a transaction using the JCA Resource Adapter.
Using Geode as the JTA Transaction Manager
You can also use Geode as the JTA transaction manager. As of Geode 1.2, Geode’s JTA transaction manager is deprecated.
Geode ships with its own implementation of a JTA transaction manager. However, note that this implementation is not XA-compliant; therefore, it does not persist any state, which could lead to an inconsistent state after recovering a crashed member.
The Geode JTA transaction manager is initialized when the Geode cache is initialized. Until then, JTA is not available for use. The application starts a JTA transaction by using the UserTransaction.begin
method. The UserTransaction
object is the application’s handle to instruct the JTA transaction manager on what to do.
The Geode JTA implementation also supports the J2EE Connector Architecture (JCA) ManagedConnectionFactory
.
The Geode implementation of JTA has the following limitations:
- Only one JDBC database instance per transaction is allowed, although you can have multiple connections to that database.
- Multiple threads cannot participate in a transaction.
- Transaction recovery after a crash is not supported.
In addition, JTA transactions are subject to the limitations of Geode cache transactions such as not being supported on regions with global scope. When a global transaction needs to access the Geode cache, JTA silently starts a Geode cache transaction.
How to Run a JTA Global Transaction Using Geode as the JTA Transaction Manager
This topic describes how to run a JTA global transaction in Geode .
To run a global transaction, perform the following steps:
- Configure the external data sources in the
cache.xml
file. See Configuring Database Connections Using JNDI for examples. - Include the JAR file for any data sources in your CLASSPATH.
- Configure Geode for any necessary transactional behavior. Enable
copy-on-read
for your cache and specify a transaction listener, if you need one. See Setting Global Copy on Read and Configuring Transaction Plug-In Event Handlers for details. - Make sure that JTA transactions are not disabled in the
cache.xml
file or the application code. - Initialize the Geode cache.
Get an initial context through
org.apache.geode.cache.GemFireCache.getJNDIContext
. For example:Context ctx = cache.getJNDIContext();
This returns
javax.naming.Context
and gives you the JNDI associated with the cache. The context contains theTransactionManager
,UserTransaction
, and any configured JDBC resource manager.Look up the
UserTransaction
context:UserTransaction txManager = (UserTransaction) ctx.lookup("java:/UserTransaction");
With
UserTransaction
, you can begin, commit, and rollback transactions. If a global transaction exists when you use the cache, it automatically joins the transaction. Operations on a region automatically detect and become associated with the existing global transaction through JTA synchronization. If the global transaction has been marked for rollback, however, the Geode cache is not allowed to enlist with that transaction. Any cache operation that causes an attempt to enlist throws aFailedSynchronizationException
.The Geode cache transaction’s commit or rollback is triggered when the global transaction commits or rolls back. When the global transaction is committed using the
UserTransaction
interface, the transactions of any registered JTA resources are committed, including the Geode cache transaction. If the cache or database transaction fails to commit, theUserTransaction
call throws aTransactionRolledBackException
. If a commit or rollback is attempted directly on a Geode transaction that is registered with JTA, that action throws anIllegalStateException
.


vision, goals, strategy
The first thing you should do when starting your orchestra is figure out what you want your orchestra to be like. Don't start recruiting musicians or making any definite plans until you know your goals. Here are some questions to think about:
Make sure your community can support the type of orchestra you want to form. Will you be able to attract enough players of the desired type? Will there be too much competition for players and/or audience from other, similar groups? If you don't already know what other groups operate in or near your area, take the time to find out before you do anything else. Even if you are starting an orchestra just for fun, you are essentially starting a business; you need to know your market.
Keep in mind that the vision and goals you have for your orchestra will have financial impact. If you're going to pay your musicians or play a lot of newer music, you're going to need more money than if all your musicians are volunteers and you play mostly older music that is out of copyright. If competition for audience is a significant factor, you can't charge too much (or anything) for tickets.
Make sure you discuss your vision and goals clearly with your potential conductor before you commit to working together; you and your conductor need to share the same goals. (If you are the conductor, find a co-founder who can help you with the administrative stuff, and make sure this co-founder shares your goals.)
Both in the beginning and as your organization grows, be realistic. You'll probably have more good ideas than you can realistically pursue, given limited resources and volunteer manpower. Be clear on what your "minimum shippable product" is.


| Application No. | Category | Student Name | Email Address | Selected Course | Action | Quantitative Aptitude Test Date |
|---|---|---|---|---|---|---|
| {{application?.enrollment_no}} | {{application?.student_category}} | {{application?.stu_name}} | {{application?.email}} | {{application?.specialization}} ({{application?.course}}) |
|
{{application?.online_test_date}} |
| Date | Application No. | Application No.For 1st Payment | Student Name | Email Address | Selected Course | Selected Intake | Action |
|---|---|---|---|---|---|---|---|
| {{data?.date}} | {{data?.enrollment_no}} | {{data?.user_id}} | {{data?.stu_name}} | {{data?.email}} | {{data?.specialization}} ({{data?.course}}) | {{data.intake_date + '/' + data.intake_month + '/' + data.intake_year + ' To ' + data.intake_to_date + '/' + data.intake_to_month + '/' + data.intake_to_year}} |
| Application No. | Category | Student Name | Email Address | Selected Course | Download Document | Action |
|---|---|---|---|---|---|---|
| {{application?.enrollment_no}} | {{application?.student_category}} | {{application?.stu_name}} | {{application?.email}} | {{application?.specialization}} ({{application?.course}}) | |
|


@import helper._ @main("About Project") {
JPL has provided a repository of web services for multi-aspect physics-based and phenomenon-oriented phenomenon-oriented climate model performance evaluation and diagnosis through the comprehensive and synergistic use of multiple observational data, reanalysis data, and model outputs.
This project aims to study various hidden relationships, including semantic relationships and usage relationships, to help users not only learn available datasets and web services, but also learn how to use them. Moreover, we aim to facilitate Earth scientists and students in designing climate analytics workflows faster than before.


computer networks
1.2 network hardware
- taxonomy of computer networks
- transmission technology
- broadcast links
- A wireless network
- broadcasting: every machine
- multicasting: subset of the machines
- point-to-point links, sometimes called unicasting
- broadcast links
- scale
- PANs (Personal Area Networks)
- Bluetooth
- The master tells the slaves
- what addresses to use,
- when they can broadcast,
- how long they can transmit,
- what frequencies they can use,and so on
- The master tells the slaves
- Bluetooth
- LAN (Local Area Network)
- a standard for wireless LANs called IEEE 802.11, popularly known as WiFi
- IEEE 802.3, popularly called Ethernet, is, by far, the most common type of wired LAN.
- MAN (Metropolitan Area Network)
- WAN (Wide Area Network)
- Internetworks
- A collection of interconnected networks is called an internetwork or internet.
- worldwide Internet (is one specific internet)
- PANs (Personal Area Networks)
- transmission technology
1.3.1 Protocol Hierarchies
- each layer passes data and control information to the layer immediately below it, until the lowest layer is reached.
- It is common that different hosts use different implementations of the same protocol
- the lower layers of a protocol hierarchy are frequently implemented in hardware or firmware
1.3.2 Design Issues for the Layers
Reliability
- bits are damaged
- errors:
- fluke electrical noise,
- random wireless signals,
- hardware flaws,
- software bugs and so on
- solution: adding redundant information, used at low layers, to protect packets sent over individual links,and high layers, to check that the right contents were received
- error detection
- Information that is incorrectly received can then be retransmitted, until it is received correctly
- error correction
- where the correct message is recovered from the possibly incorrect bits that were originally received
- error detection
- errors:
- finding a working path through a network
- may be some links or routers that are broken
- routing: The network should automatically make this decision
the evolution of the network
- protocol layering
- internetworking, different network technologies often have different limitations .ex:
- number messages
- not all communication channels preserve the order of messages sent on them
- differences in the maximum size of a message that the networks can transmit
- disassembling, transmitting, and then reassembling messages
- number messages
- traffic jams
- internetworking, different network technologies often have different limitations .ex:
resource allocation
- statistical multiplexing
- share the bandwith dynamically, rather than by giving each host a fixed fraction
- sharing based on the statistics of demand
- how to keep a fast sender from swamping a slow receiver with data
- flow control: feedback from the receiver
- congestion: network is oversubscribed, overloading
- too many computers want to send too much traffic
- the network cannot deliver it all
- resource
- bandwidth
- timeliness
- live video
- real-time
security
- eavesdropping[ secretly listening to the private conversation]
- solution: provide confidentiality
- authentication: prevent someone from impersonating someone else
- integrity: prevent surreptitious changes to messages
- solution: provide confidentiality
1.3.3 Connection-Oriented Versus Connectionless Service
Connection-oriented
- Connection-oriented service is modeled after the telephone system.
- establish
- use
- release
- service is modeled after the telephone system.
- A circuit is another name for a connection with associated resources
- fixed bandwidth
- in some case negotiation parameters
- maximum message size
- quality of service required
-
one side make proposal, the other accept reject make a counterproposal
- acts like a tube:
- sender pushes at one end , receiver takes them at the other end
- in most case the order is preserved: bits arrive in the order they were sent
Connectionless Service
- connectionless service is modeled after the postal system
- each msg carries the full destination address
- a packet is a message at the network layer
- store-and-forward switching：
- nodes receive a message in full before sending it to the next
- cut-through switching:
- onward transmission of a message at a node starts before it is completely received
- order is not consistant because of delayed
reliability
both Connection-Oriented or Connectionless Service can further be characterized by its reliability
- implemented by having the receiver acknowledge the receipt of each msg
- Reliable connection-oriented service has two minor variations:
- message sequences
- message boundaries are preserved
- byte streams
- no message boundaries
- Unreliable (meaning not acknowledged) connectionless service is often called datagram service
- does not return an acknowledgement to the sender
- dominant form in most networks
- reliable communication (in our sense, that is,acknowledged) may not be available in a given layer
- Ethernet does not provide reliable communication
- many reliable services are built on top of an unreliable datagram service
- the delays inherent in providing a reliable service may be unacceptable, especially in real-time applications such as multimedia
1.3.4 Service Primitives
A service is formally specified by a set of primitives (operations) available to user processes to access the service
- tell the service to perform some action or report on an action taken by a peer entity
- system calls
- cause a trap to kernel mode
- send the necessary packets
steps
six packets are required to complete the protocol
- server executes LISTEN to indicate that it is prepared to accept incoming connections.
- system call
- server process blocked until a request for connection appears
- send packets
- 1.client executes CONNECT to establish a connection with the server
- sends a packet to the peer asking it to connect
- parameter of server’s address
- client suspended until a response
- 2.server can then establish the connection with the ACCEPT call
- send a response to accept
- arrival of response release the client
- client && server now both running and have a connection established
- 1.client executes CONNECT to establish a connection with the server
- server to execute RECEIVE to prepare to accept the first request
- block the server
- when
- normally immediately being released from the LISTEN
- before the acknowledgement can get back to the client
- send packets
- 3.client executes SEND to transmit its request
- client: followed by execution of RECEIVE to get the reply
- server: arrivial of request unblock the server to handle the request
- 4.server: use SEND to return the answer
- client: arrivial of the packet unblock the cient
- additional requsts can go on(if have)
- 3.client executes SEND to transmit its request
- send packets
- 5.client: when done, executes DISCONNECT to terminate the connection
- an initial DISCONNECT is a blocking call, suspending the client
- sending a packet to the server saying that the connection is no longer needed
- 6.server: gets the packet
- issues a DISCONNECT of its own
- acknowledging the client and releasing the connection
- client receive the packet
- client process is released
- connection is broken
- 5.client: when done, executes DISCONNECT to terminate the connection
issues
- timing can be wrong (e.g., the CONNECT is done before the LISTEN),
- packets can get lost
- why not connectionless:
- in perfect world only two packets would be needed
- request
- reply
- but
- large messages in either direction (e.g., a megabyte file),
- transmission errors,
- lost packets
- in perfect world only two packets would be needed
problems of connectionless
- if packets lost, how would the client know if some pieces were missing?
- How would the client know whether the last packet actually received was really the last packet sent?
- How could it tell packet 1 from the second file from a lost packet 1 from the first file that suddenly found its way to the client?
1.3.5 services vs protocols
- service
- like api
- is a set of primitives that a layer provides to the layer above it
- relates to an interface between two layers
- lower layer -> service provider
- upper layer -> service user
- protocol
- like impl
- relate to the packtets
- is a set of rules relate to packets
- governing the format and meaning of
- the packets,
- or messages that are exchanged by the peer entities within a layer.
- governing the format and meaning of
- Many older protocols did not distinguish the service from the protocol
- a typical layer might have had a service primitive SEND PACKET with the user providing a pointer to a fully assembled packet.
- all changes to the protocol were immediately visible to the users —– violate the rule/ a serious blunder
1.4 OSI Model && TCP/IP Model
- osi
- protocols not used any more
- model itself quite general && valid
- features at each layer are still very important
- TCP/IP
- the model itself is not of much use
- the protocols are widely used.
1.4.1 OSI
- developed by the International Standards Organization (ISO)
- ISO OSI (Open Systems Interconnection) Reference Model
- means open for communication with other systems
- OSI model itself is not a network architecture
- it does not specify the exact services and protocols to be used in each layer
- just tell what each layers should do
- produced standards for all layers
- these are not part of refernce model itself
- it does not specify the exact services and protocols to be used in each layer
model(in part) widely used, protocols are long forgotten
1.4.1 OSI model layers
physical layer
- concerned with transmitting raw bits
- Typical questions
- what electrical signals should be used to represent a 1 and a 0,
- how many nanoseconds a bit lasts,
- whether transmission may proceed simultaneously in both directions,
- how the initial connection is established,
- how it is torn down when both sides are finished,
- how many pins the network connector has, and what each pin is used for.
data link layer
- transform a raw transmission facility into a line that appears free of undetected transmission errors
- by masking the real errors so the network layer does not see them
- break up the input data into data frames
- transmit the frames sequentially
- receiver confirms each frame by sending back an acknowledgement frame.
- issues
- how to keep a fast transmitter from drowning a slow receiver in data.
- some traffic regulation mechanism want to konw when the receiver can accept more data
- Broadcast networks : how to control access to the shared channel.
- A special sublayer added: medium access control sublayer
the network layer
- controls the operations of the subnet
- determining how packets are routed from source to destination.
- handling congestion
- the quality of service provided (delay, transit time, jitter, etc.
- allow heterogeneous networks to be interconnected
- different network may be different
- in addressing
- packet might be too large
- protocol may differ
- different network may be different
the transport layer
- basic function
- accept data from above it,
- split it up into smaller units if need be,
- pass these to the network layer,
- and ensure that the pieces all arrive correctly at the other end.
- determines what type of service to provide to the session layer, and, ultimately, to the users of the network–determined when connection is established
- most popular: error-free point-to-point channel
- delivers messages or bytes in the order in which they were sent.
- others
- transporting of isolated messages with no guarantee about the order of delivery
- the broadcasting of messages to multiple destinations.
- most popular: error-free point-to-point channel
- true end-to-end layer
- carries data from source to destination
- message headers
- control message
- lower layers not end-2-end
- each protocols is between a machine and its immediate neighbors,
- not between the ultimate source and destination machines,
- separated by many routers
- carries data from source to destination
the session layer
- allows users on different machines to establish sessions between them.
- dialog control
- (keeping track of whose turn it is to transmit),
- token management
- (preventing two parties from attempting the same critical operation simultaneously)
- synchronization
- (checkpointing long transmissions to allow them to pick up from where they left off in the event of a crash and subsequent recovery).
- dialog control
presentation layer
- concerned with the syntax and semantics of the information transmitted.
Application Layer
- ex. http
1.4.2 The TCP/IP Reference Model
history
- ARPANET
- using leased telephone lines
- connect hundreds of universities and government
- trouble with interworking with satellite and radio networks
- a new reference architecture was needed –> tcp/ip
- goals
- connect multiple networks in a seamless way
- be able to survive loss of subnet hardware(Soviet Union attack)
- others:
- transferring files
- real-time speech transmission,
- goals
The Link Layer
- describes what links such as serial lines and classic Ethernet must do to meet the needs of this connectionless internet layer.
The Internet Layer
- linchpin that holds the whole architecture together
- deliver IP packets where they are supposed to go
- IP (Internet Protocol): official packet format and protoco
- ICMP (Internet Control Message Protocol)
- issues
- Packet routing
- congestion
the transport layer
- allow peer entities on the source and destination hosts to carry on a conversation
- end-to-end transport protocols
- TCP(Transmission Control Protocol)
- reliable connection-oriented protocol
- handles flow control to make sure a fast sender cannot swamp a slow receiver
- UDP (User Datagram Protocol)
- unreliable, connectionless protocol
- for applications that do not want TCP’s sequencing or flow control and wish to provide their own
- widely used
- one-shot, client-server-type request-reply queries
- applications in which prompt delivery is more important than accurate delivery
- such as transmitting speech or video.
- TCP(Transmission Control Protocol)
- end-to-end transport protocols
The Application Layer
- virtual terminal (TELNET),
- file transfer (FTP),
- and electronic mail (SMTP)
- Domain Name System (DNS)
- HTTP, the protocol for fetching pages on the World Wide Web,
- RTP, the protocol for delivering real-time media such as voice or movies
1.4.4 OSI vs TCP/IP [compare in reference modules not the corresponding protocol stacks]
- layers:
- osi: 4 layers
- tcp/ip: 7 layers
- both: layers up through and including the transport layer provide an end-to-end, network-independent transport service to processes wishing to communicate
- OSI devised before the corresponding protocols
- tcp/ip:protocols come first,
- model was really just a description of the existing protocols
- no problems with protocols fitting the model, but model did not fit any other protocol stacks
- it was not especially useful for describing other, non-TCP/IP networks.
Three concepts are central to the OSI model:
-
- Services.[methods , operations]
- tells what the layer does,
- not how entities above it access it or how the layer works.
- It defines the layer’s semantics.
- Services.[methods , operations]
-
- Interfaces.[methods’ parameter && result]
- tells the processes above it how to access it
- specific parameters
- not or how the layer works.
- Interfaces.[methods’ parameter && result]
-
- Protocols.[code internal]
- the layer’s own business.
- can use any protocols to finish its work
- Protocols.[code internal]
The TCP/IP model did not originally clearly distinguish between services, interfaces, and protocols
- ex. the only real services offered by the internet layer are SEND IP PACKET and RECEIVE IP PACKET
- the protocols in the OSI model compare that in the TCP/IP model
- better hidden
- replaced relatively easily as the technology changes
connectionless vs connection-oriented
- osi
- support both in network layer
- only connection-oriented in transport layer
- tcp/ip
- connectionless in network layer
- both in transport layer
- giving the user a choice–important for simple request-response protocols
1.4.5 critique of osi
bad timing
- TCP/IP protocols were already in widespread use by research universities by the time the OSI protocols appeared
- When OSI came around, they did not want to support a second protocol stack until they were forced to
bad technology
- seven layers was more political than technical, and two of the layers
- (session and presentation) are nearly empty,
- (data link and network) are overfull.
- extraordinarily complex
- difficult to implement and inefficient in operation
- functions, such as addressing, flow control, and error control, reappear again and again in each layer.
- unnecessary and inefficient.
bad implementations
- implementations were huge, unwieldy, and slow.
- In contrast, one of the first implementations of TCP/IP was part of Berkeley UNIX and was quite good && free
bad politics
- TCP/IP was thought as part of UNIX
- osi supported by the government but not work
1.4.6 critique of tcp/ip
- not clearly distinguish the concepts of services, interfaces, and protocols.
- not much of a guide for designing new networks using new technologies
- the TCP/IP model is not at all general and is poorly suited to describing any protocol stack other than TCP/IP.
- ex: completely impossible to use the TCP/IP model to describe Bluetooth
- the link layer is not a layer
- it is an interface between the network and data link layer
- does not distinguish between the physical and data link layers.
- physical layer:
- copper wire, fiber optics, and wireless communication
- data link layer:
- delimit the start and end of frames and get them from one side to the other with the desired degree of reliability.
- physical layer:
- some protocols are ad hoc,
- ex. TELNET–The virtual terminal protocol
- was designed for a ten-character-per-second mechanical Teletype terminal.
- knows nothing of graphical user interfaces and mice
- but still in used some 30 years later
- ex. TELNET–The virtual terminal protocol
Ad hoc是拉丁文常用短语中的一个短语。这个短语的意思是“特设的、特定目的的（地）、即席的、临时的、将就的、专案的”。这个短语通常用来形容一些特殊的、不能用于其它方面的的，为一个特定的问题、任务而专门设定的解决方案
1.5.1 the internet
not really a network at all
- a vast collection of different networks
- use certain common protocols
- provide certain common services
The ARPANET
- 1950 DoD wants a command-and-control network that could survive a nuclear war.
- telephone network
- 1960s, Baran proposed using digital packet-switching technology. AT&T dismissed
- 1957, Soviet Union launch of the first artificial satellite, Sputnik–beat US
- President Eisenhower–ARPA, the Advanced Research Projects Agency.
- 1967, ARPA – ARPANET (minicomputers + IMPs[Interface Message Processors])
- first electronic storeand-forward packet-switching network
- NPL system – National Physical Laboratory in England
- demonstrated that packet switching could be made to work
- 1967, ARPA – ARPANET (minicomputers + IMPs[Interface Message Processors])
- President Eisenhower–ARPA, the Advanced Research Projects Agency.
- an experimental network went online
- 1969 with four nodes: at UCLA, UCSB, SRI, and the University of Utah.
- all had a large number of ARPA contracts
- all had different and completely incompatible host computers (just to make it more fun).
- ARPA also funded research on the use of satellite networks and mobile packet radio networks
- demonstrated that the existing ARPANET protocols were not suitable for running over different networks
- 1974–TCP/IP was specifically designed to handle communication over internetworks
- 1969 with four nodes: at UCLA, UCSB, SRI, and the University of Utah.
- ARPA awarded several contracts to implement TCP/IP on different computer platforms,
- IBM, DEC, and HP systems, as well as for Berkeley UNIX.
- Berkeley UNIX–rewrote TCP/IP with a new programming interface called sockets for the upcoming 4.2BSD release of Berkeley UNIX
- 1980s, additional networks, especially LANs, connected to the ARPANET
- DNS(Domain Name System) was created
NSFNET
- 1970s, NSF (the U.S. National Science Foundation) saw enormous impact of ARPANET
- fund the Computer Science Network (CSNET) in 1981,
- have to have a research contract with the DoD to get on ARPANET, many have no contract
- connect to ARPANET via dial-up and leased lines
- backbone network to connect supercomputer centers
- Each supercomputer given a microcomputer called a fuzzball
- fuzzball connected with 56kb lines to form subnet
- same hardware technology the ARPANET used
- fuzzball use TCP/IP right from the start—first TCP/IP WAN
- fuzzball connected with 56kb lines to form subnet
- Each supercomputer given a microcomputer called a fuzzball
- NSFNET: the complete network
- funded some regional networks connected to the backbone
- NSF encouraged MERIT, MCI, and IBM to form a nonprofit corporation, ANS (Advanced Networks and Services)
- ANS took over NSFNET and upgraded to form ANSNET
- 5 years later sold to America Online
- NSF awarded contracts to four different network operators to establish a NAP (Network Access Point)
- To ease the transition && make sure regional networks could communicate with each other
- fund the Computer Science Network (CSNET) in 1981,
- 1990s, many other countries and regions also built national research networks,
- often patterned on the ARPANET and NSFNET
1.5.1 Architecture of the Internet
- ISP: Internet Service Provider
- DSL: Digital Subscriber Line
- DSL modem
- modem is short for ‘modulator demodulator’ and refers to any device that converts between digital bits and analog signals.
- DSLAM (Digital Subscriber Line Access Multiplexer)
- DSL modem
- DSL + telephone line : dial-up
- limited to 56 kbps
- DSL + cable : much greater
- FTTH (Fiber to the Home)
- optical fiber, 光纤
- POP (Point of Presence)
- the ISP’s POP: locaiton at which customer packets enter the ISP network for service
- TV system
- cable modem
- CMTS (Cable Modem Termination System)
- ISP’s POP (Point of Presence).
- backbone
- long-distance transmission lines that interconnect routers at POPs in the different cities that the ISPs serve
- IXPs (Internet eXchange Points)
- ISPs connect their networks to exchange traffic at IXPs
- Basically, an IXP is a room full of routers,
- at least one per ISP
- A LAN in the room connects all the routers
- a small ISP might pay a larger ISP for Internet connectivity
- two large ISPs might decide to exchange traffic
- packet’s path
- depends on the peering choices of the ISPs
- with destination ISP :directly to its peer
- or else route the packet to the nearest paid transit provider
- depends on the peering choices of the ISPs
- tier 1 ISPs
- form the backbone of the Internet
- thousands of routers connected by high-bandwidth fiber optic links
- AT&T, Sprint…
- data centers
- Google, Yahoo…
- server farm: rack upon rack of machines
- Colocation/hosting (机器托管)
- short, fast connections can be made between the servers and the ISP backbones
1.5.2 Mobile Phone Networks
generation
AMPS : Advanced Mobile Phone System , 1G
1
2
- transmitted voice calls as continuously varying(Analog) signals
- each voice call on a specific frequency band
GSM : Global System for Mobile communications
1
2
3
4
5
- transmitting voice calls in digital form #### UMTS (Universal Mobile Telecommunications System) || WCDMA (Wideband Code Division Multiple Access)
- offer both digital voice and broadband digital data services
- each cell to use all frequencies,
- a tolerable level of interference to the neighboring cells.
- based on Code Division Multiple Access (CDMA)
radio access network
1
2
3
- cellular base station
- controller node or RNC (Radio Network Controller)
- controls how the spectrum is used.
core network: carries the traffic for the radio access network
- UMTS core network evolved from 2G GSM system’s core network
- connectionless subnets–packet networks
- if too many packets, router will choke and lose packets
- sender will resend but service will be jerky
- if too many packets, router will choke and lose packets
- connection-oriented subnets–circuit networks
- set up establishes a route
- all words or packets follow the same route
- if a line or switch on the path goes down, call is aborted
- support quality of service more easily
- subnet can reserve resources(link bandwidth, switch buffer space, CPU)
- if resource is insufficient, call will be rejected
- once a connection is connected, connection would get good service
- set up establishes a route
- connectionless subnets–packet networks
- old mobile phone networks–connectionless
- MSC (Mobile Switching Center), GMSC (Gateway Mobile Switching Center)
- MGW (Media Gateway) elements that set up connections over a circuit-switched core network such as the PSTN (Public Switched Telephone Network).
- GPRS(General Packet Radio Service)
- ran at tens of kbps
- UMTS core network nodes connect directly to a packet-switched network
- SGSN (Serving GPRS Support Node) and the GGSN (Gateway GPRS Support Node)
- voice calls over a packet data network
issues
- handover
- soft handover
- connect to the new base station before disconnecting from the old base station
- hard handover
- soft handover
- how to find a mobile in the first place when there is an incoming call
- Each mobile phone network has a HSS (Home Subscriber Server)
- the location of each subscriber,
- profile information that is used for authentication and authorization
- Each mobile phone network has a HSS (Home Subscriber Server)
- security
- SIM card, short for Subscriber Identity Module
- authenticate subscribers
- cryptographic keys on the SIM card are used to encrypt transmissions
- SIM card, short for Subscriber Identity Module
1.5.3 wifi, 802.11
- operate in unlicensed bands such as the ISM (Industrial, Scientific, and Medical) bands
- defined by ITU-R (e.g., 902-928 MHz, 2.4-2.5 GHz, 5.725-5.825 GHz).
- two style
- Wired network with APs(access points)
- ad hoc network: clients talk directly
- multipath fading
- radio signals reflected off solid objects
- multiple echoes of a transmission
- cancel
- reinforce
- multiple echoes of a transmission
- solutions:
- path diersity: sending along multiple, independent paths
- using different frequencies
- repeating bits over different periods of time
- radio signals reflected off solid objects
- multiple transmissions collide
- CSMA (Carrier Sense Multiple Access)
- Computers wait for a short random interval before transmitting, and defer their transmissions if they hear that someone else is already transmitting
- CSMA (Carrier Sense Multiple Access)
- security
- WEP (Wired Equivalent Privacy)
- WiFi Protected Access, initially called WPA but now replaced by WPA2
1.5.4 RFID and Sensor Networks
Radio Frequency IDentification (RFID)
- consists of a small microchip with a unique identifier and an antenna that receives radio transmissions.
battery
- passive RFID
- all of the energy needed to operate them is supplied in the form of radio waves by RFID readers.
- active RFID
- there is a power source on the tag
distance
- UHF RFID (Ultra-High Frequency RFID).
- shipping pallets and some drivers licenses
- backscatter：Tags communicate at distances of several meters by changing the way they reflect the reader signals
- HF RFID (High Frequency RFID)
- passport, credit cards, books, and noncontact payment systems
- based on induction
- LFRFID (Low Frequency RFID)
- for animal tracking
problem
- multiple tags
- tags wait for a short random interval before responding with their identification
- security
- weak measures: like passwords
sensor network
- Sensor nodes are small computers
- self-organize to relay messages for each other
1.7 METRIC UNITS
https://gimg2.baidu.com/image_search/src=http%3A%2F%2Fslideplayer.com%2F5675735%2F18%2Fimages%2F4%2FMetric%2BConversion%2BChart.jpg&refer=http%3A%2F%2Fslideplayer.com&app=2002&size=f9999,10000&q=a80&n=0&g=0n&fmt=jpeg?sec=1622127822&t=f468c0add4a2c6f3b629c2b95844ce87
3.1 data link layer
uses the services of the physical layer to send and receive bits over communication channels
- Providing a well-defined service interface to the network layer.
- Dealing with transmission errors.
- Regulating the flow of data
3.1.1 services provided to the natwork layer
Unacknowledged connectionless service.
having the source machine send independent frames to the destination machine without having the destination machine acknowledge them
- ex. Ethernet,
- no logical connection
- if a frame is lost, no attempt to detect the loss or recover
- appropriate when the error rate is very low, appropriate for real-time traffic, such as voice
Acknowledged connectionless service.
- no logical connections
- each frame sent is individually acknowledged
- is useful over unreliable channels, such as wireless systems. ex. 802.11 (WiFi)
Acknowledged connection-oriented service
providing acknowledgements in the data link layer is just an optimization, never a requirement
- can send packets and wait for ack, resend when expired
- inefficient,
- network layer does not know hardware parameters, and send a big packet(ex.10 frames, 2 lost):
- links have a strict maximum frame length imposed by hardware
- known propagation delays.
- On reliable channels, such as fiber, the overhead of a heavyweight data link protocol may be unnecessary,
- but on (inherently unreliable) wireless channels it is well worth the cost
connection-oriented
- Each frame sent over the connection is numbered,
- guarantees that each frame sent is indeed received.
- guarantees that each frame is received exactly once and that all frames are received in the right order.
- appropriate over long, unreliable links such as a satellite channel or a long-distance telephone circuit.
- if connectionless, cause a frame to be sent and received several times, wasting bandwidth.
3.1.2 framing
- channel is noisy
- Breaking up the bit stream into frames
- Byte count.
- 无法解决乱序问题
- Flag bytes with byte stuffing.
- two consecutive flag bytes indicate the end of one frame and the start of the next
- insert special escape byte(ESC) to avoid interfering
- flaw: tied to the use of 8-bit bytes
- Flag bits with bit stuffing.
- framing done at the bit level
- Each frame begins and ends with a special bit pattern, 01111110 or 0x7E in hexadecimal.
- to avoid conflict in the body
- sender: stuffs 0, when encounters five consecutive 1s
- receiver: automatically destuffs the 0 bits when sees
- to avoid conflict in the body
- Physical layer coding violations.
- Byte count.
A common pattern used for Ethernet and 802.11 is to have a frame begin with a well-defined pattern called a preamble.
3.1.3 Error Control
ensure that each frame is ultimately passed to the network layer at the destination exactly once, no more and no less
- provide the sender with some feedback
- positive ack: arrived
- negative ack: something go wrong
- if a frame vanish?
- introducing timers
- expire after an interval
- introducing timers
- if either the frame or the ack is lost?
- just transmit the frame again
- if sender transmit the same frame multiple times, receiver accept the same frame two or more time
- assign sequence numbers to outgoing frames
3.1.4 flow control
a sender that systematically wants to transmit frames faster than the receiver can accept them.
issues
- sender: a fast, powerful computer and the receiver: a slow, low-end machine.
- phone request a web page from powerful server
commonly used approaches
- feedback-based flow control
- receivers send back information to the sender to send more data
- or at least telling the sender how the receiver is doing
- rate-based flow control
- the protocol has a built-in mechanism that limits the rate at which senders may transmit data,
- without using feedback from the receiver.
feedback vs rate
- Feedback-based schemes are seen at both the link layer and higher layers
- more common:
- the link layer hardware is designed to run fast enough that it does not cause loss.
- hardware implementations of the link layer as NICs (Network Interface Cards) can handle frames as fast as they can arrive on the link
- so handled by higher layers
- various feedback-based flow control schemes: the same basic principle
- well-defined rules about when a sender may transmit the next frame.
- These rules often prohibit frames from being sent until the receiver has granted permission,
- more common:
- rate-based schemes are only seen as part of the transport layer
3.2 ERROR DETECTION AND CORRECTION
strategies dealing with errors
-
error-correcting codes FEC (Forward Error Correction). - include enough redundant information to enable the receiver to deduce what the transmitted data must have been.
- used On channels that are highly reliable, such as fiber
- it is cheaper to use an error-detecting code and just retransmit the occasional block found to be faulty
- seen in the physical layer, particularly for noisy channels
- in higher layers, particularly for real-time media and content distribution
- error-detecting codes
- include only enough redundancy to allow the receiver to deduce that an error has occurred (but not which error)
- have it request a retransmission.
- FEC is used on noisy channels because retransmissions are just as likely to be in error as the first transmission
- wireless links: make many errors
- commonly used in link, network, and transport layers
- include only enough redundancy to allow the receiver to deduce that an error has occurred (but not which error)
Neither error-correcting codes nor error-detecting codes can handle all possible errors
3.2.1 Error-correcting codes–todo
- Hamming codes.
- Binary convolutional codes.
- Reed-Solomon codes.
- Low-Density Parity Check codes.
3.2.2 Error-Detecting Codes–todo
- Parity.
- Checksums.
- Cyclic Redundancy Checks (CRCs).
3.4 sliding window
The network layer, in contrast, is always fed data in the proper order, regardless of the data link layer’s window size
- each outbound frame contains a sequence number,ranging from 0 up to some maximum.
- sender maintains a set of sequence numbers corresponding to frames it is permitted to send.
- These frames are said to fall within the sending window
- receiver also maintains a receiving window corresponding to the set of frames it is permitted to accept.
sequence number in sender
- The sequence numbers within the sender’s window represent
- frames that have been sent
- or can be sent but are as yet not acknowledged.
- maintains a list of unacknowledged frames
- when a new packet arrives
- it is given the next highest sequence number,
- the upper edge of the window is advanced by one
- when a new packet arrives
sequence number in receiver
- frame receive,
- if (frame.sq == window.lowerEdge)
- it is passed to network layer
- window is rotated by one
- any frame falling outside the window is discarded
- if (frame.sq == window.lowerEdge)
- ack
- a window size of 1 means that the data link layer only accepts frames in order,
- but for larger windows this is not so
- a window size of 1 means that the data link layer only accepts frames in order,
3.4.1 Sliding Window Protocol
go-back-n
is for the receiver simply to discard all subsequent frames, sending no acknowledgements for the discarded frames.
selective repeat
a bad frame that is received is discarded, but any good frames received after it are accepted and buffered.
flow control
error control
4 the medium access control sublayer
5.1.2 Services Provided to the Transport Layer
provides services to the transport layer
rules:
- The services should be independent of the router technology
- transport layer should be shielded from the number, type, and topology of the routers present
- network addresses should use a uniform numbering plan, even across LANs and WANs
two camps
- connectionoriented service
- routers’job is moving packets around and nothing else
- host: error control(error detection and correction) && flow control
- connectionless service
- represented by telephone companies
- ATM vs IP
- connection-oriented technologies
- MPLS (MultiProtocol Label Switching)
- VLANs
5.2.1 the optimality principle
6.1.1 Services Provided to the Upper Layers
different kinds similar with network service
- connection-oriented
- connectionless,
why need transport layer
make the transport service to be more reliable
- The transport code runs entirely on the users’ machines, but the network layer mostly runs on the routers
- routers operated by the carrier
- users have no real control over network layer
- cannot solve the problem of poor service by using better routers
- cannot putting more error handling in the data link layer
- solution: put on top of the network layer another layer–transport layer
- packets are lost or mangled in connectionless
- transport layer detect the problem and compensate for it by retransmit
- in connnection-oriented network, connection is abrutly terminated
- set up new network connection
- packets are lost or mangled in connectionless
hiding the network service behind a set of transport service primitives
- transport primitives can be implemented as call to library procedures
- independent of the network primimitives
- application programmers can write code according to a standard set of primitives
- without having to worry about different network interfaces and reliability
transport layer–key position
- the bottom four layers–transport service provider
- the upper layers –transport service user
6.1.2
6.1.3 Berkeley Sockets
what
- A common transport layer interface
- another set of transport primitives,
- Sockets the de facto standard for abstracting transport services to applications.
- often used with the TCP protocol to provide a connection-oriented service called a reliable byte stream
- other protocols work as well
- used with a connectionless transport service
- often used with the TCP protocol to provide a connection-oriented service called a reliable byte stream
parameters of the call specify
- the addressing format to be used,
- the type of service desired (e.g., reliable byte stream),
- and the protocol
The socket primitives for TCP
- SOCKET Create a new communication endpoint
- BIND Associate a local address with a socket
- LISTEN Announce willingness to accept connections; give queue size
- ACCEPT Passively establish an incoming connection
- CONNECT Actively attempt to establish a connection
- SEND Send some data over the connection
- RECEIVE Receive some data from the connection
- CLOSE Release the connection
6.2 transport protocol vs data link protocol
major difference: operating environment
data link layer – communicate directly via a physical channel(wired wireless)
transport layer – communicate via the entire network
addressing
- data link layer:
- not necessary for a router to specify which router it wants to talk to
- transport layer:
- addressing of destinations is required
establishing a connection
- data link layer : simple
- the other end is always there
- transport layer: complicated
the potential existence of storage capacity in the network
- data link layer:
- a packet may arrive or be lost
- transport layer:
- delay and duplicate packets
- take scenic route
- arrive late
- out of expected order
- delay and duplicate packets
degree: buffering and flow control
- data link layer:
- a large and varying number of connections with bandwith that fluctuates
- not buffers to each line
- transport layer:
- buffers to each line
6.2.2 connection establishment
network can lose, delay, corrupt, duplicate packets
issues e.g.
- delayed in the network and pop out much later, when the sender thought that they had been lost
prevent packets from being duplicated and delayed
- …
- throwaway transport addresses
- more difficult to connect with a process in the first place
- give each connection a unique identifier
- requires each transport entity to maitain a certain amount of history infomation indefinitely
- throwaway transport addresses
- kill off aged packets that hobbling about
- restricted network design – prevents packets from looping
- hop counter
- timestamping